Tesis Desarrollo de Un Punto de Venta

UNIVERSIDAD NACIONAL AUTÓNOMA DE MÉXICO
FACULTAD DE ESTUDIOS SUPERIORES CUAUTITLÁN
DESARROLLO DE UN PUNTO DE VENTA COMO APLICACIÓN WEB

SIGUIENDO UNA METODOLOGÍA ÁGIL BAJO UN MODELO DE
DISTRIBUCIÓN DE SOFTWARE COMO SERVICIO.
TESIS
PARA OBTENER EL TÍTULO DE
LICENCIADO EN INFORMÁTICA
PRESENTAN
ANA KAREN DE LA LUZ OLIVA
SERGIO MORLÁN PÁRAMO
ASESOR
MA. VALENTÍN ROLDÁN VÁZQUEZ
CUAUTITLÁN IZCALLI, ESTADO DE MÉXICO 2014

UNAM – Dirección General de Bibliotecas
Tesis Digitales
Restricciones de uso
DERECHOS RESERVADOS ©
PROHIBIDA SU REPRODUCCIÓN TOTAL O PARCIAL
Todo el material contenido en esta tesis esta protegido por la Ley Federal
del Derecho de Autor (LFDA) de los Estados Unidos Mexicanos (México).
El uso de imágenes, fragmentos de videos, y demás material que sea

objeto de protección de los derechos de autor, será exclusivamente para
fines educativos e informativos y deberá citar la fuente donde la obtuvo
mencionando el autor o autores. Cualquier uso distinto como el lucro,
reproducción, edición o modificación, será perseguido y sancionado por el
respectivo titular de los Derechos de Autor.
ÍNDICE
INTRODUCCIÓN……………….……………………...…………………………………..…1
CAPÍTULO I
MIPYMES DEL COMERCIO AL POR MENOR
1.1 Introducción...……..………………………….…………………………………..……5
1.2 Empresa………………………………………………………………………………..6
1.3 MiPyME………………………………………………………………………..............6
1.4 Sector Comercial…………………………..…………………………………………..9
1.4.1 MiPyMEs del Sector Comercial al Por Menor……………..…...............11
CAPÍTULO II
APLICACIONES WEB
2.1 Antecedentes…..…….………………………………………………………….……13
2.2 Aplicación...……..………………………………………………………………….…14
2.3 Aplicación de Escritorio.…...……………………………………………………...…14
2.4 Aplicación Web.…………....………………...………………………...………….…14
2.4.1 Características de una Aplicación Web.………………...………………16
2.4.2 Arquitectura de las Aplicaciones Web.………………...………………..16
2.4.2.1 Capa o Nivel 1.………………………….……...……………….18
2.4.2.2 Capa o Nivel 2.………………………….……...……………….19
2.4.2.3 Capa o Nivel 3.………………………….……...…………….....20
2.5 Aplicación Web VS Aplicación de Escritorio.……………………...…………….…21
2.6 Protocolo TCP/IP…………………………………………………………………..…21
2.7 Protocolo HTTP……………………………………………………... ………………23
2.8 Word Wide Web.………………………………...…………………...………………23
2.9 Entornos Web…………………….……………………………..…... ………………24
2.10 Patrón de Diseño de Software en las Aplicaciones Web. ………………………26
2.10.1 Modelo Vista Controlador…………………………………………...…..27
2.10.2 Patrón de Arquitectura de Software Utilizado………...……………….28
2.11 Ventajas de las Aplicaciones Web.…………………...………... ….…………….30
2.12 Inconvenientes de las Aplicaciones Web.….…………….……... ………………30
CAPÍTULO III
TECNOLOGÍAS PARA LA CONSTRUCCIÓN DE APLICACIONES WEB
3.1 Introducción………………...………………………………………………………...32
3.2 Capa 1 (Cliente)……………………………………………………………..............32
3.2.1 Navegador Web…………………………………….…………….............32
3.2.2 HTML…………….………………………………….……………..............34
3.2.2.1 HTML5…………….……………………………………............35
3.2.3 CSS…………….………………………………………………….............36
3.2.4 JavaScript…........................................................................................37
3.2.4.1 jQuery………………………...………..……….………............38
3.2.4.2 Ajax………………………………………………………………39
3.2.5 DOM……………………………………………………………..………….39
3.3 Capa 2 (Servidor Web)……………………………………………………...............40
3.3.1 Lenguajes de Programación Web……………………………................40
3.3.1.1 PHP…...................................................................................41
3.3.2 Framework……………………………………………………..................44
3.3.2.1 Symfony………………………………………………...............45
3.3.3 Servidor Web……………………………………………………...............46
3.3.3.1 Servidor HTTP Apache…………………………..…...............48
3.4 Capa 3 (Servidor de Datos)………….……………………………….….................49
3.4.1 Bases de Datos………………………………..………...........................49
3.4.2 SQL………………………………………………………………...............50
3.4.3 Sistema Gestor de Bases de Datos………………………….................51
3.4.3.1 MySQL……….......................................................................52
3.4.4 Modelos de Datos……….....................................................................53
3.4.4.1 Modelo Relacional……….....................................................54
3.4.4.2 Modelo Entidad-Relación………...........................................55
3.4.4.3 Diagrama Entidad-Relación……………………….................56
3.4.5 ORM…………………………………………………………….................57
3.4.5.1 Doctrine………………………………………………...............57
3.5 Otras tecnologías de desarrollo………………………………………...................58
3.5.1 UML…………………………………………………...…………………....58
3.5.2 Twig…………………………………………………………...…………....60
3.5.3 JSON………………………..………………………………………...…....61
CAPÍTULO IV
SEGURIDAD EN APLICACIONES WEB
4.1 Introducción…………………………………………………………………………..64
4.2 Cross-Site Scripting (XSS)…………………………….……………...…………….67
4.3 Cross-Site Request Forgery (CSRF)...……………………………………………..70
4.4 Inyección SQL....................................................................................................71
4.5 Encriptación de Datos...…………………………..……...……….....…..………….76
4.6 Autenticación y Autorización…..………………………..……………….………….79
4.7 Espionaje (Sniffing)...……………………………………...……………..………….81
4.8 Desbordamiento...……….………………………….................………..………….82
4.9 Envenenamiento Cookies…………………………...…………...…………………84
CAPÍTULO V
PROTECCIÓN DE DATOS
5.1 Introducción...……..……………………………………………………………….....87
5.2 Datos Personales…………………………………………………………………….88
5.3 Protección de Datos………………………………………………………………….89
5.4 Instituto Federal de Acceso a la Información y Protección de Datos…………….92
5.5 Ley Federal de Protección de Datos Personales en Posesión de Particulares...94
5.5.1 Fase 1: Obtención y uso de datos………………..……………………...96
5.5.2 Fase 2: Tratamiento de los datos………………………..…….…………97
5.5.3 Fase 3: Conclusión del uso de los datos personales………...…………97
5.6 Aviso de Privacidad……………………………………………………..…………...98
5.7 Derechos ARCO…………………………………………………………...............102
5.7.1 Acceso…………………………………………………………………….102
5.7.2 Rectificación…………………………………………………………...…103
5.7.3 Cancelación……………………………………………………………....103
5.7.4 Oposición………………………………………………………………....104
CAPÍTULO VI
MODELOS DE DISTRIBUCIÓN DE SOFTWARE
6.1 Preámbulo...……….…..……...……...…………………………………………….107
6.1.1 Web 2.0…...………………………………………….……..…………….108
6.1.2 Cloud Computing…...……………….……………………..…………….110
6.4 Modelos de Distribución de Software…...………………………………………...114
6.5 Software Local…...……………………………………………………..…………..115
6.6 Software como Servicio…...……………………………………...………………..117
6.6.1 Ventajas del Software como Servicio…...……………………………..123
6.6.1.1 Ventajas para el Cliente…...………………………………….123
6.6.1.2 Ventajas para el Proveedor…...…………………………...…124
6.6.2 Inconvenientes del Software como Servicio…...……………………...124
6.6.2.1 Inconvenientes para el Cliente…...………………………….125
6.6.2.2 Inconvenientes para el Proveedor…...………………………125
6.7 Freemium…...…………………………………………………………..............….126
CAPÍTULO VII
PUNTO DE VENTA
7.1 Introducción...………..…………………………………….………………………..129
7.2 Terminal Punto de Venta…………………………………………..……………….130
7.3 ARTS……………………………………………………………………………...…131
7.3.1 Modelo de Datos………………………………………………...............131
7.3.2 Unified POS…………………………………………………...………….132
7.3.3 ARTS XML………………………………………………..………………133
7.4 Terminal Punto de Venta en la nube………………………….………………..…134
7.4.1 Características de un Punto de Venta…………………………….……135
7.4.2 Beneficios de una Terminal Punto de Venta………………………..…136
CAPÍTULO VIII
METODOLOGÍA ÁGIL DE DESARROLLO DE SOFTWARE
8.1Introducción…………………………………………………………………….…………….138
8.2 Metodologías Tradicionales……………………………………………………….139
8.3 Metodologías Ágiles……………………………………………...………………...140
8.4 Metodologías Tradicionales vs Metodologías Ágiles…………..…..…………...145
8.5 Programación Extrema…………………………………………………………….146
8.5.1 Ciclo de Vida de Programación Extrema……………………………....150
8.5.2 Desarrollo Incremental…………………………………………………..151
8.5.3 Programación en Parejas……………………………...….…………….152
8.5.4 Integración Continúa…………………………………..…….…………..153
8.5.5 Artefactos…………………………………………………………………155
8.6 Programación Extrema y UML……………………………………..……………...160
CASO PRÁCTICO
DESARROLLO DE UN SISTEMA PUNTO DE VENTA EN LA NUBE
1 Estudio de Mercado..…..…………………………………….……………….……...162
1.1 Análisis de consumidor……………………………………….…………...162
1.2 Análisis de competencia………………………………………….............165
1.3 Estrategia………………………………………………………….............168
2 Análisis y Requerimientos Iterativos…..…………………….….…………………..169
2.1 Historias de usuario (hasta la última liberación)……………….………..170
3 Diseño Iterativo (Final).…………….….……………….…………………...............172
4 Desarrollo Iterativo (Final) con Integración continua…….….….………...............172
5 Implementación.…………………….….………………...…...................................178
ANEXOS
A.- Tablas Comparativas de Tecnologías...…..…………………..............……..…..181
B.- Aviso de Privacidad………..……..…………………..…..………………………...189
C.- Manifiesto por el Desarrollo Ágil de Software…...…..…..……………………….191
D.- Manual de Usuario...……..…………………...………..…..………………………192
PROYECCIONES A FUTURO….……………………………………………....................193
CONCLUSIONES...……..………………………………………………………...................194
BIBLIOGRAFÍA...……..…………………….…………………………………………………198
Índice de Figuras
Figura 1.1 Imagen que ilustra la clasificación de MiPyMEs de acuerdo a la

estratificación de empresas publicada en el Diario Oficial de la Federación el 30 de junio de
2009…………………………………..……………………………………………………………...8
Figura 1.2 Gráfico que muestra los sectores de la economía

mexicana……………………………………………………………………….…………...……..10
Figura 1.3 Gráfico que muestra el porcentaje de unidades económicas que proveen
las MiPyMEs del sector comercial al por mayor y al por
menor...…………………………..……..................................................................................11
Figura 2.1 Arquitectura de 3 capas o niveles de una Aplicación Web……………….17
Figura 2.2 Patrón de Arquitectura Hibrido utilizado en el desarrollo de esta

tesis…………………………………………………………………………………………………29
Figura 3.1 Gráfico extraído del sitio Web W3Counter que muestra la participación
en el mercado de los navegadores más dominantes a nivel mundial hasta Abril de 2013 en
porcentajes…………………………………………………………….………………………..…34
Figura 3.2 Gráfico de Netcraft que muestra el crecimiento a nivel mundial de la

cantidad de host que utilizan PHP hasta Enero de 2012…………………………..…………..43
Figura 3.3 Gráfico de Netcraft que muestra el uso mundial de los Servidores Web
más populares hasta abril de 2013……………………..…………………………………….…47
Figura 3.4 Tabla comparativa de algunos los tipos de SGBD más utilizados………51
Figura 3.5 Ejemplo de persistencia de un objeto DQL con Doctrine 2………………58
Figura 3.6 Ejemplo de plantilla HTML usando PHP ‘puro’.………………...…………60
Figura 3.7 Ejemplo de plantilla HTML usando el motor de plantillas Twig….………61
Figura 3.8 Ejemplo de JSON……………………………………………………………62

Figura 4.1 Panorama general de aspectos de seguridad básica en una Aplicación
Web………………….…………………………………………………………………………..…65
Figura 4.2 Gráfica de los resultados obtenidos del informe de las tendencias en
vulnerabilidad de las aplicaciones en 2013 realizado por Cenzic………………………….…68
Figura 4.3 Escapado de caracteres con htmlspecialchars de PHP……………....…69
Figura 4.4 Ejemplo común ocultar una URL para hacer un ataque CSFR….…....…70
Figura 4.5 Protección contra CSFR mediante un token provisto por Symfony….…71
Figura 4.6 Ejemplo de consulta a base de datos sin protección de escapado de

caracteres………………………………………………………………………………………….72
Figura 4.7 Ejemplo de Inyección SQL en el campo de un formulario………………..73
Figura 4.8 Cadena de texto resultante que es interpretado como una instrucción
SQL…………………………………………………………………………………………………73
Figura 4.9 Escapado de una cadena de texto recibida desde un formulario con
mysql_real_escape_string de PHP……………………………………………………………...74
Figura 4.10 Ejemplo de protección contra inyección SQL con Doctrine y su método
setParameter con sentencias por nombre……………………………………………………...75
Figura 4.11 Ejemplo de protección contra inyección SQL con Doctrine y su método
setParameter con sentencias por posición.…………………..………………………………...75
Figura 4.12 Ejemplo de encriptación de una contraseña utilizando Symfony………76
Figura 4.13 Ejemplo de configuración del archivo YAML access_control para

asignar permisos de acceso……………………………………………………………………..80
Figura 5.1 Balanza representativa de los aspectos que influyen el uso de las redes
sociales…………………………………………………………………………………………….90
Figura 5.2 Logotipo del Instituto Federal de Acceso a la Información y Protección de

Datos de 2013…………………….…………………………………………………………….…92
Figura 5.3 Imagen que ilustra algunos aspectos que abarca el aviso de privacidad
y quienes lo requieren………………………………………………………..………………….100
Figura 6.1 Modelos del Cómputo en la Nube………………………………...………112
Figura 6.2 Representación de las acciones básicas del lado del cliente (Cloud
Client)………………………..……………………………………………………………………113
Figura 6.3 Taba que muestra las proyecciones del mercado de SaaS por región
geográfica según datos de Gartner de 2011……………………………………..……………120
Figura 6.4 Grafico representativo del modelo ASP y SaaS……………….………..121
Figura 8.1 Diagramas representativos de las metodologías tradicional en cascada y

ágil………………………………………………………………………………………………...143
Figura 8.2 Diagramas representativos de las metodologías tradicional RUP y

ágil…………………………………………………………….…………………………………..144
Figura 8.3 Tabla comparativa entre Metodología Ágil contra una Metodología
Tradicional…………………………………………………………….………………………....145
Figura 8.4 Gráfico de la estructura de Programación Extrema (XP) con tiempos

aproximados…………………………………………………………………………….……….147
Figura 8.5 Gráfico representativo del ciclo de vida de la Programación Extrema

(XP)……………………………………………………………………………………………….150
Figura 8.6 Gráfico representativo del funcionamiento de SVC en la nube………154
Figura 8.7 Formato de artefacto Historia de usuario para XP………………………157
Figura 8.8 Formato de artefacto Caso de Aceptación de Pruebas para XP…...….156
Figura 8.9 Formato de artefacto Tarea de Ingeniería para XP……………………..159
Figura C.1 Ingresos de las empresas del sector comercial en México 2008 de
acuerdo con datos del último censo económico de 2009 del INEGI………………………...162
Figura C.2 Ingresos de las principales ramas de comercio al por menor de acuerdo
con INEGI…………………….…………………………………………………………………..163
Figura C.3 Porcentaje de ingresos de las principales ramas del comercio al por
menor de las MiPyMES en México 2008 de acuerdo con datos del último censo económico
de 2009 del INEGI……………………………………………………….………………………163
Figura C.4 Tabla de competencia de Sistemas punto de venta que operan con
tecnologías Web…………………………..…………………………………………………..…167
Figura C.5 Hoja 1 de las principales historias de usuario (hasta la última

iteración)…………………………………………………………….……………………………170
Figura C.6 Hoja 2 de las principales historias de usuario (hasta la última

iteración)………………………………………………………………………………………….171
Figura C.7 Código QR que envía a la dirección de GitHub que contiene el código y
otros archivos del sistema……………………………………………………...……...............172
Figura C.8 Diagrama general de las principales clases del sistema……………….173
Figura C.9 Diagrama detallado de navegación en el sistema………………………175
Figura C.10 Diagrama Entidad Relación de la Base de Datos. ……………………177
Figura C.11 Configuración de Servidor Virtual en Apache………………………….178

Página |1
Introducción
Con el uso de los sistemas de cómputo para la automatización de procesos

productivos, y la adopción de las aplicaciones basadas en la Web a partir de la
segunda mitad de la década de los 90’s por parte de empresas, instituciones y la
sociedad en general, han hecho que el conocimiento llegue a constituirse en el
principal factor de la producción.
El uso de las TIC (Tecnologías de la Información y la Comunicación) puede

incrementar ganancias, abarcar nuevos mercados, mejorar y actualizar las
empresas y con ello simplificar, acelerar y hacer más seguros los procesos de los
negocio, lo que te lleva a ser más eficiente y generar crecimiento.
“En el campo económico, la caída de las barreras al comercio, la reducción

significativa de los costos de transporte de bienes y servicios, y el uso intensivo de
las TICs, han facilitado el incremento de las transacciones comerciales,
presionando a los países y a sus empresas, en especial a las PYMEs, a ser más
competitivas, en todos los sectores.” 1
En México actualmente hay más de 4 millones unidades empresariales

existentes de las cuales la mayor parte (99% aproximadamente) son micro,
pequeñas y medianas empresas. De las cuales más de la mitad pertenece al
sector comercial y principalmente del comercio al por menor.
_________________________________________________________________________
1 Ricardo Monge. G., Cindy Alfaro. A., José I. Alfaro. C. (2005). TICs en las PYMES de
Centroamérica, Impacto de la adopción de las tecnologías de la información y la
comunicación en el desempeño de las empresas. Costa Rica: Editorial Tecnológica de
Costa Rica.
Página |2
Las empresas dedicadas al comercio al por menor, tienen necesidades muy

similares sin importar el volumen de sus ventas, una de sus principales
necesidades está basada en las operaciones de compra y venta, necesidad que
suele solucionarse mediante la implantación de algún software que controle y
administre dichas operaciones como lo es una Terminal Punto de Venta o POS
(del inglés Point Of Sale).
La tendencia actual y la infraestructura con la que se cuenta hoy en día

enfocan la mayor parte de los desarrollos hacia aquellos basados en lo que se
conoce como la Nube, Internet o la Web, ofreciendo múltiples ventajas frente a las
aplicaciones tradicionales instaladas en los equipos del cliente, entre las que
destacan su gran escalabilidad, amplia captación de clientes y alta disponibilidad.
El desarrollo de un POS creado como Aplicación Web conlleva muchas

ventajas anteriormente mencionadas. El mantenimiento del sistema resulta menos
costoso ya que este se realiza vía remota, al igual que nuevos registros,
actualización o eliminación. “Una ventaja clave del uso de aplicaciones web es que
el problema de gestionar el código en el cliente se reduce drásticamente.” 2
Siguiendo el esquema de distribución de Software como Servicio para

ofrecer el POS basado en la Web permite a los clientes (MiPyMEs del ámbito
Comercial al por menor, para el caso de esta tesis) adquirir un producto con una
inversión inicial muy baja y obtener un sistema para la automatización y control de
sus procesos siempre actualizado y disponible.
__________________________________________________________________
2 Sergio Luján Mora. (2001). Programación en Internet: clientes web. España: Club Universitario.
p.8.
Página |3
“cada vez más organizaciones están dejando de comprar licencias de

software y montarlas sobre máquinas propias para pasar a comprar acceso
<<como servicio>>” 3
El uso de tecnologías libres permite que el costo de desarrollo y

mantenimiento disminuya, y de esta forma tener un precio muy competitivo en el
mercado. La elección de lenguajes ampliamente conocidos y soportados como
PHP y JavaScript justifican su utilización por su amplia documentación y fácil
acceso a la misma, además de contar con una gran comunidad inmersa y
especialista en estas tecnologías. El Framework Symfony, provee una estructura
robusta y estandarizada la cual facilita la escalabilidad del sistema a futuro,
además de ofrecer seguridad, una característica de suma importancia en las
aplicaciones basadas en la Web.
__________________________________________________________________
3 Accid. (2010). Nuevas Tendencias en Management: Fundamentos y Aplicaciones. Madrid,
España: Bresca. p. 115.
CAPÍTULO I
MIPYMES DEL COMERCIO AL POR MENOR
Página |5
1.1 Introducción
Con los avances tecnológicos actuales y un aumento de la sociedad adaptada a

las Tecnologías de la Información (TI), exigen que incluso los pequeños negocios
cuenten con Sistemas de Información que permitan tomar decisiones inmediatas y
precisas para mejorar su competitividad en el mercado.
Ahora en nuestros días, nos hemos percatado que en la economía mexicana las
PyMES, son capaces de generar bienes y servicios para satisfacer las necesidades del
ser humano pero también nos hemos percatado de las deficiencias que tienen para
llevar el control administrativo y en ocasiones, de los recursos con los que cuentan. Es
por esto la necesidad de implementar sistemas informáticos que ayuden al micro,
pequeña y mediana empresa a resolver los problemas de control de información de sus
negocios para poder facilitar la toma de decisiones.
La pequeña y mediana empresa proporciona más de la mitad de todos los

empleos en México, incluyendo actividades que no son comerciales. Tal cifra se va
incrementando conforme se automatizan, cada vez más, las grandes empresas con la
correspondiente reducción de sus nóminas de pago.
Página |6
1.2 Empresa
Una empresa la podemos definir como la entidad integrada por capital

monetario, trabajo y factores de producción que se dedican a diferentes
actividades que pueden ser industriales, mercantiles o de prestación de servicios que
buscan lucrar para obtener un beneficio.
Las características generales de una empresa se enlistan a continuación:
1. Recursos humanos, de capital, técnicos y financieros.

2. Realizar un bien o servicio para satisfacer necesidades humanas.
3. Planean sus actividades de acuerdo a los objetivos que desean alcanzar.
4. Son un instrumento muy importante del proceso de crecimiento y desarrollo
económico y social.
5. Para sobrevivir debe de competir con otras empresas, lo que exige:
modernización, racionalización y programación.
6. Generar puestos de trabajo.
7. Obtener rentabilidad.
1.3 MiPyME
Es el término utilizado para referirse a las micro, pequeña y mediana empresa,

las cuales constituyen un factor elemental en la economía nacional ya que representan
el 99.87 % de las empresas mexicanas.
Página |7
De las cuales 4 millones 743 unidades empresariales son micro y pequeña

empresa (95.2 % de estas compañías son microempresas, el 4.3 % son pequeñas
empresas y el 0.3 % son medianas). 1
Las MiPYME generan el 52 % del PIB y el 72 % de empleo en México esto

según Censo Económico de INEGI realizado en 2009.2
Normalmente para la clasificación de las empresas por su tamaño se toman

criterios que van desde la cantidad de trabajadores así como el tamaño de sus
ingresos. La cantidad de trabajadores es un criterio que en ocasiones tiene poco que
ver al momento de clasificar a una empresa como pequeña, mediana o micro, ya que
se han registrado empresas con hasta 500 trabajadores, que aún son catalogadas
como pequeña o mediana empresa.
Para México las PYMES, son parte fundamental de la economía e

indispensable para el crecimiento de económico. Tenemos una sólida base de
empresarios que pertenecen a la Micro, Pequeña y Mediana empresa, claramente más
sólida que muchos otros países del mundo, debemos aprovecharla para hacer de eso
una fortaleza que haga competitivo al país, que se convierta en una ventaja real para
atraer nuevas inversiones y fortalecer la presencia de productos mexicanos tanto
dentro como fuera de nuestra nación
______________________________________________________________________
1 Instituto Nacional de Estadística y Geografía. (2009). Micro, pequeña, mediana y gran empresa
Estratificación de los establecimientos, Censos Económicos 2009, Aguascalientes, Estados
Unidos Mexicanos: [s.n]. p 7.
2 PyMES, eslabón fundamental para el crecimiento en México. (s.f.). Recuperado el 22 de mayo de
2013 de http://www.promexico.gob.mx/negocios-internacionales/pymes-eslabon-fundamental-
para-el-crecimiento-en-mexico.html.
Página |8
La Secretaría de Economía (SE) y la Secretaría de Hacienda y Crédito Público

(SHCP) son quienes establecen las clasificaciones de las PYMES en México con la
finalidad de poder establecer programas de apoyo encaminado a cada empresa
según su clasificación.
Figura 1.1 Imagen que ilustra la clasificación de MiPyMEs de acuerdo a la estratificación de empresas
publicada en el Diario Oficial de la Federación el 30 de junio de 2009.
Página |9
“Las empresas micro, pequeñas y medianas representan a nivel mundial el

segmento de la economía que aporta el mayor número de unidades económicas y
personal ocupado” 3
Podemos mencionar algunas de las ventajas de las Pymes:
 Las PYMES son el principal motor dentro de la economía de México.

 Pueden ampliarse, disminuir su tamaño, cambiar de ubicación, cambiar los
procesos técnicos que realizan entre otras.
 Pueden alcanzar una escalabilidad y convertirse en una empresa grande.
 Son principales generadoras de empleo en cualquiera de los sectores.
 Son muy flexibles y se adaptan a la implementación de nuevas tecnologías.
 Las PYMES pueden estar establecidas en diferentes regiones del país y
contribuyen al desarrollo local y regional por sus efectos multiplicadores.
 Facilidad en la toma de decisiones ya que cuentan con una práctica
administración.
1.4 Sector Comercial
Según el números obtenidos del Censo Económico de 2009 de comercios en el

país, esta actividad es la más abundante, ya que una de cada dos unidades
económicas (49.9%) se dedicaron al Comercio.
______________________________________________________________________
Unidos Mexicanos: [s.n].p 11.
P á g i n a | 10
SECTORES ECONÓMICOS EN MÉXICO

Manufacturas
Servicios 11.7
36.7
Otros Comercio
1.7 49.9
Figura 1.2 Gráfico que muestra los sectores de la economía mexicana.
Las actividades comerciales están clasificadas en dos sectores: Comercio al por

mayor y Comercio al por menor.
 Comercio al por mayor: Comprende las unidades económicas dedicadas

principalmente a la compra-venta (sin realizar la transformación) de bienes de
capital, materias primas y suministros en grandes cantidades.
 Comercio al por menor: Incluye unidades dedicadas a la compra-venta de
bienes para el uso personal o para el hogar, compra-venta de productos en
pequeñas cantidades.
P á g i n a | 11
1.4.1 MiPyMEs del Sector Comercial al Por Menor
Las unidades económicas percibidas por MiPyMEs que se encuentran en el

sector comercial fueron 1, 368,546 en 2009 de los cuales la mayor parte corresponde a
aquellas que pertenecen al comercio al por menor, entre negocios dedicados a venta
de abarrotes y alimentos, tiendas de autoservicio, ropa y accesorios de vestir,
ferretería, tlapalería y vidrios, papelerías, libros y revistas, artículos para el cuidado de
la salud, etc.
UNIDADES ECONÓMICAS DE MIPYMES

COMERCIALES EN MÉXICO DE 2009
Al por
Mayor 4%
Al por
Menor
96%
Figura 1.3 Gráfico que muestra el porcentaje de unidades económicas que proveen las MiPyMEs del
sector comercial al por mayor y al por menor.
Los Sistemas Punto de Venta están especialmente enfocados a ventas al por

menor, de acuerdo a la delimitación de esta tesis el sistema desarrollado sólo
se contempla para MiPyMEs del ámbito comercial al por menor. Aunque no
se descarta la posibilidad de incrementar la segmentación de mercado en un
futuro.
CAPÍTULO II
APLICACIONES WEB
P á g i n a | 13
2.1 Antecedentes
En la arquitectura cliente-servidor, sin el uso de la Web, cada aplicación tiene

su propio programa cliente que sirve como interfaz de usuario y debe ser instalado
por separado en cada computadora de cada usuario. De esta forma el cliente realiza
peticiones a otro programa ubicado en el servidor que brinda una respuesta. Esta
arquitectura crea una dependencia muy fuerte entre la aplicación del cliente y el
Sistema Operativo en el que es ejecutado. Normalmente las mejoras en el servidor,
requirieren una mejora de los clientes instalados en cada ordenador personal, esto
aumenta sus costos de soporte técnico y disminuye la productividad.
Las Aplicaciones Web funcionan de una forma diferente al modo

anteriormente mencionado, ya que, la lógica es enviada a los clientes mediante
scripts que residen en el servidor y son actualizados desde ese lugar. “Las
aplicaciones Web se encuadran dentro de las arquitecturas cliente-servidor” 1. Las
Aplicaciones Web generan dinámicamente una serie de páginas en un formato
estandarizado, como HTML o XHTML, y que pude ser visualizado desde cualquier
Navegador Web en cualquier dispositivo. Hasta cierto punto el Navegador Web
juega el papel cliente, pero en realidad va más allá puesto que se encarga de
visualizar toda la lógica contenida en cada aplicación ejecutada del lado del cliente,
y tiene la capacidad de ejecutar múltiples aplicaciones, que bajo el otro modelo sería
necesario instalar un cliente por cada aplicación ejecutada. Para la construcción de
Aplicaciones Web se utilizan lenguajes interpretados en el lado del cliente como
JavaScript, de esta forma el Navegador Web interpreta y muestra en pantalla las
páginas.
__________________________________________________________________
1 Luján Mora S. (2001). Programación en Internet: clientes web. España: Club Universitario. p.8.
P á g i n a | 14
2.2 Aplicación
Es un programa informático, que cumple un objetivo específico, funcionando

como herramienta para la elaboración automatizada de determinadas tarea, como
por ejemplo, procesadores de texto, hojas de cálculo, aplicaciones para diseño
asistido, diseño gráfico, Navegadores Web, etc.
2.3 Aplicación de Escritorio
Se trata de una aplicación que requiere ser instalada en el equipo del

usuario, se le denomina de esta forma (aplicación de escritorio) ya que la mayoría
de las interfaces de usuario de los Sistemas Operativos opera bajo una metáfora de
escrito la cual simula ser un escritorio físico. Siempre que un programa tenga que
ser instalado en el equipo del cliente se le denominará aplicación de escritorio
aunque esta reciba datos remotos, como por ejemplo, TweetDeck (cliente para
Twitter), Thunderbird (cliente de mensajería), Microsoft Word 2013, etc.
2.4 Aplicación Web
Una aplicación web es un tipo especial de aplicación cliente/servidor donde

tanto el cliente como el servidor y el protocolo mediante el que se comunican
(HTTP) están estandarizados. Suelen distinguirse tres niveles: nivel superior que
interacciona con el usuario (Navegador Web), nivel intermedio que procesa los
datos (servidor web) y el nivel inferior que proporciona los datos (base de datos).
P á g i n a | 15
La ejecución de las Aplicaciones Web se realiza mediante un navegador

que interpreta y muestra al cliente la aplicación. Anteriormente para enriquecer
la experiencia de usuario se utilizaban diversas tecnologías tales como ActiveX,
applet Java y Flash, que se ejecutaban a manera de complementos o plug-in, los
cuales mejoraban la interacción del cliente en el Navegador Web y el tratamiento de
archivos locales, sin embargo estos complementos requieren una instalación más
en el cliente y necesitan actualizaciones constantes, lo cual disipa la esencia de las
Aplicaciones Web, sin embargo los navegadores cuentan con tecnologías nativas
que son suficientes para la creación de Aplicaciones Web del lado del cliente, como
lo son JavaScript y HTML, además la evolución de estas mismas tecnologías (como
HTML5, por ejemplo) actualmente permiten crear aplicaciones sumamente robustas
capaces de competir e incluso superar la experiencia del usuario ante una aplicación
instalada el Cliente o ante una Aplicación Web utilizando plug-ins.
Este sistema será desarrollado como Aplicación Web sin utilizar plug-ins,
siguiendo así una filosofía de ‘listo para usarse’ además de no crear límites
entre las distintas plataformas en las que se ejecute utilizando como ejemplo:
en iOS de Apple la tecnología Flash no funciona.
P á g i n a | 16
2.4.1 Características de una Aplicación Web.
 No requiere instalación en el equipo del cliente, sólo se necesita un

Navegador Web para acceder a la aplicación.
 Su construcción puede dividirse en dos o tres niveles.
 La lógica de negocio se encuentra en el servidor.
 Los elementos de la Interfaz Gráfica de Usuario son mostrados por el
Navegador Web al Cliente.
 Los datos y la información con la que trabaja la Aplicación Web siempre son
almacenados remotamente.
 Es necesario un Servidor Web con algún lenguaje que generé páginas
dinámicas.
 La aplicación no depende del Sistema Operativo del cliente y puede
ejecutarse en cualquier dispositivo con conexión a Internet y un navegador.
2.4.2 Arquitectura de las Aplicaciones Web
La arquitectura de una aplicación define como se organizan los distintos

módulos que componen a un sistema. Existen 2 arquitecturas para construir
Aplicaciones Web, la arquitectura de dos niveles y la arquitectura de tres niveles. La
diferencia entre ellas estriba en la forma de distribución de la Aplicación y el
Servidor.
“El objetivo de aumentar el número de niveles en una aplicación distribuida

es lograr una mayor independencia entre un nivel y otro” 2
_________________________________________________________________
P á g i n a | 17
La arquitectura de dos niveles o capas está basada en un Servidor con un

Sistema Gestor de Bases de Datos (SGBD) y Clientes que mantienen la lógica de
presentación, negocio y acceso a los datos.
En la arquitectura de tres niveles o capas, la lógica de presentación, la

lógica de negocio y la lógica de datos están separadas. En su forma más común,
el Navegador Web ofrece la primera capa y un motor capaz de usar alguna
tecnología Web dinámica constituye una capa intermedia. Por último, una base de
datos constituye la tercera y última capa.
Figura 2.1 Arquitectura de 3 capas o niveles de una Aplicación Web.

P á g i n a | 18
La Arquitectura de 3 capas o niveles, resulta mucho más escalable, la

modularidad que ofrece permite que en un futuro (si es que la demanda lo
requiere) puedan migrarse con menor dificultad a otra tecnología, ya que
cada nivel cuenta con cierta independencia del resto. Es por ello que se ha
seleccionado esta arquitectura para el desarrollo de esta tesis.
2.4.2.1 Capa o Nivel 1
El nivel de la Interfaz Gráfica de Usuario está compuesto por documentos

en distintos formatos como páginas HTML, documentos CSS y documentos con
algún tipo de script que el usuario solicita a un Servidor Web y que visualiza en el
cliente normalmente con un Navegador Web utilizando tecnologías como:
o JavaScript.
o Applets (Java).
o ActiveX (Microsoft).
o Silverlight (Microsoft).
o JavaFX (Java).
o Flash (Adobe).
Como ya se mencionó anteriormente de las tecnologías expuestas arriba,

sólo JavaScript es nativo en la inmensa mayoría de los Navegadores Web actuales,
tanto así que es difícil imaginar un navegador que no pueda ejecutar JavaScript.
P á g i n a | 19
La lógica de negocio es el siguiente nivel que se está compuesto por los

módulos que implementan la lógica de la aplicación y que se ejecutan en un
Servidor Web, es aquí donde son utilizados los lenguajes de programación como:
o ASP
o PHP
o ColdFusion
o Servlets (Java)
o JSP (Java)
o Python
o Ruby
Es en esta capa donde se ejecutan gran parte de los procesos necesarios

encargados de la lógica de negocios de la Aplicación Web. Y comprende una serie
de rutinas que realizan entradas de datos, consultas a los datos, generación de
informes y más específicamente todo el procesamiento que se realiza detrás de la
aplicación visible para el usuario. Es aquí donde parte de la lógica implica la
utilización de patrones tales como Modelo Vista Controlador que se verá más
adelante.
P á g i n a | 20
El tercer nivel corresponde a los datos y está compuesto por la

información, normalmente administrada por un Sistema Gestor de Bases de Datos
(SGBD), que maneja la Aplicación Web. Algunos de los SGBD más utilizados son
los siguientes:
o Oracle (Oracle Corporation)

o MySQL (Oracle)
o PostgreSQL (PostgreSQL Global Development Group)
o Microsoft SQL Server (Microsoft)
o DB2 (IBM)
Es aquí donde la información con la cual funciona el sistema es alojada, esta

capa no necesariamente debe estar físicamente separada de la capa 2, ambos
niveles pueden estar contenidos dentro del mismo equipo y dicho equipo cumpliría
la función de dos servidores al mismo tiempo, tanto Servidor Web como Servidor de
Datos.
P á g i n a | 21
2.5 Aplicación Web VS Aplicación de Escritorio
Ninguna es mejor que la otra, ambos tipos de aplicación tienen ventajas y

desventajas ante determinados problemas a solucionar, el tipo de tareas que se
realizaran, los niveles de seguridad necesarios de acuerdo al tipo de información
manejada y de acuerdo a su factibilidad económica.
La tendencia actual apunta hacia un modelo de distribución de software en el

cual el procesamiento de datos es ‘compartido’ y una parte de este se realiza de
manera remota, parte de esta tendencia es marcada por el uso de distintos
dispositivos móviles que se encuentran conectados a Internet y permiten a los
usuarios acceder a las Aplicaciones Web, principalmente, en cualquier lugar y
tiempo.
2.6 Protocolo TCP/IP
El TCP/IP es un conjunto o familia de protocolos de red que permiten la

transmisión de datos entre computadoras y lo componen el Protocolo de
Transmisión (TCP) y Protocolo de Internet (IP). Está conformado por más de 100
protocolos diferentes, entre ellos se encuentra el popular HTTP (HyperText Transfer
Protocol).
P á g i n a | 22
“El término ‘TCP / IP’ significa generalmente cualquier cosa y todo en relación
con los protocolos específicos de TCP e IP. Se pueden incluir otros protocolos,
aplicaciones y hasta el medio de la red. Una muestra de estos protocolos son: UDP,
ARP, ICMP. Y una muestra de estas aplicaciones son: TELNET, FTP y rcp. Un
término más preciso es ‘La tecnología de internet’. Una red que utiliza la tecnología
de Internet es llamado ‘internet’.” 3
TCP/IP es la base de Internet, y sirve para enlazar computadoras que utilizan

diferentes sistemas operativos. En una pila de protocolos, cada nivel resuelve una
serie de tareas relacionadas con la transmisión de datos, y proporciona un servicio
bien definido a los niveles más altos. Puede describirse por analogía con el modelo
OSI (Open System Interconnection), aunque en la práctica no corresponde
exactamente con el modelo en Internet y el modelo TCP/IP es el que realmente se
usa.
La selección del tipo de aplicación para el desarrollo de esta tesis

(Aplicación Web), se fundamenta no sólo por la tendencia actual, sino
también por la gran capacidad que han demostrado las Aplicaciones Web
para la captación de clientes, además de ofrecer un servicio de este tipo que
sería pionero en México, como el primer Sistema Punto de Venta Web en
español.
__________________________________________________________________
3 RFC 1180 A TCP/IP Tutorial [RFC 1180 Un Tutorial TCP/IP]. (Junio de 1991). Recuperado el 25
de marzo de 2013 de http://tools.ietf.org/html/rfc1180#page-12.
P á g i n a | 23
2.7 Protocolo HTTP
Es un protocolo que define la forma en que se tienen que crear y enviar los
mensajes y que acciones debe tomar el servidor y el cliente en respuesta a un
determinado comando.
“El Protocolo de Transferencia de Hipertexto (HTTP) es un protocolo de nivel

aplicación de los sistemas de información hipermedia distribuidos y colaborativos
Es genérico y sin estado, el protocolo que se puede utilizar para muchas tareas más
allá de su uso para hipertexto, tales como servidores de nombres y sistemas de
gestión de objetos distribuidos, a través de la extensión de sus métodos de petición,
códigos de error y encabezados.” 4
2.8 Word Wide Web
La Word Wide Web (WWW) es una red informática mundial, un sistema

diseñado para la distribución de información basada en hipertexto y permite que sea
accesible a través de algún entorno Web (Internet, intranet, extranet).
“Sistema de Servidores Web conectados a Internet (no todos los ordenadores

conectados a Internet forman parte de la WWW). Su protocolo de comunicación es
HTTP, su lenguaje de creación de documentos HTML y sus sistema de
direccionamiento de los recursos URL.” 5
__________________________________________________________________
5 RFC 2616 - Hypertext Transfer Protocol. (Junio de 1999). Recuperado el 20 de marzo de 2013 de
http://tools.ietf.org/html/rfc2616.
P á g i n a | 24
Fue creada por el inglés Sir Timothy John Berners-Lee en conjunto con
Robert Cailliau en el CERN de Ginebra Suiza en 1989 y finalmente publicado en
1992.
Berners Lee dirige desde 2007 el World Wide Web Consortium (W3C), el cual
desarrolla y mantiene los estándares que permiten a las computadoras conectadas
a la Web almacenar y compartir efectivamente la información.
WWW no es el único sistema de hipertexto que ha existido, anteriormente

existía un servicio llamado HyperCard pero este era propietario y para su uso era
necesaria una licencia.
El uso del prefijo ‘www’ no está impuesto por ningún estándar aunque es muy
común encontrarlo al comienzo de las direcciones web debido a la costumbre de
nombrar a los host de Internet (los servidores) con los servicios que proporcionan.
2.9 Entornos Web
La ejecución de las Aplicaciones Web depende de un Navegador Web que

mediante los estándares creados para la WWW envía y recibe los datos por el
protocolo HTTP hacia un Servidor Web, para que esta comunicación se lleve a cabo
se emplean tres entornos informáticos muy similares, todos ellos son redes
diseñadas para compartir información y basados en los protocolos de TCP/IP.
P á g i n a | 25
 Internet: Es una red global que conecta a millones de ordenadores

por todo el mundo. Su nacimiento se sitúa en 1969, en un proyecto de
investigación del Departamento de Defensa de Estados Unidos.
Posee un diseño descentralizado. "El Internet es todo el mundo y su
capacidad de difusión, un mecanismo para compartir información, y un
medio para la colaboración y la interacción entre los individuos y sus
computadoras sin tener en cuenta la ubicación geográfica." 6
 Intranet: También conocida como LAN, es una red de computadoras

basadas en protocolos de Internet (TCP/IP), que pertenece a una
organización y que es accesible únicamente por los miembros de
dicha organización, empleados u otras personas con autorización.
Una Intranet puede o no estar conectada a Internet.
 Extranet: Se trata de una Intranet que permite el acceso parcial a

personas ajenas a la organización propietaria de la Intranet.
Normalmente el acceso de personas externas se realiza con un
nombre de usuario y contraseña que los identifica como personas
autorizadas.
Debido al tipo de distribución que se le pretende dar a este sistema, el

entorno Web que será utilizado es el Internet, aunado a que la segmentación
de clientes realizada es muy amplia debido a que este sistema puede ser
utilizado por cualquier negocio que realice ventas al por menor.
__________________________________________________________________
6 M. Leiner B., et al. (2009). A Brief History of the Internet [Una Breve Historia Del Internet]. Nueva
York, Estados Unidos de América: ACM. p 22.
P á g i n a | 26
2.10 Patrón de Arquitectura de Software en las

Aplicaciones Web
El patrón de arquitectura de software ofrece una descripción de los

elementos y el tipo de relación que tienen junto con un conjunto de restricciones
sobre cómo pueden ser usados. El patrón de arquitectura comunica un esquema
de organización y no es una arquitectura como tal. Más bien es una
conceptualización de los elementos esenciales del software.
“La arquitectura de software, tiene que ver con el diseño y la implementación

de estructuras de software de alto nivel. Es el resultado de ensamblar un cierto
número de elementos arquitectónicos de forma adecuada para satisfacer la mayor
funcionalidad y requerimientos de desempeño de un sistema, así como
requerimientos no funcionales, como la confiabilidad, escalabilidad, portabilidad, y
disponibilidad.” 7. Algunos de los patrones arquitectónicos de software más
conocidos son:
 Programación por capas

 Invocación implícita
 Arquitectura en pizarra
 Arquitectura dirigida por eventos, Presentación-abstracción-control
 Peer-to-peer
 Arquitectura orientada a servicios
 Modelo Vista Controlador
__________________________________________________________________
7 Kruchten P. (1995). Architectural Blueprints—The “4+1” View Model of Software Architecture
[Planos Arquitectonicos: El “4+1” de la Arquitectura de Software Modelo Vista]. En IEEE
Software (pp. 42-50). (Vol. 12). Estados Unidos de América: [s.n]. p 2.
P á g i n a | 27
2.10.1 Modelo-Vista-Controlador
Es un patrón de arquitectura de software que separa la presentación de

información que interactúa con el usuario, el acceso a la información y los eventos
que responden a determinada acción.
 Modelo: Podría verse como una abstracción de la base de datos, el

‘modelo’ proporciona acceso a la información almacenada en el
Servidor de Datos y gestiona su acceso mediante privilegios, también
contiene reglas de negocio que transforman la información de acuerdo
a las solicitudes de los usuarios. El modelo no tiene comunicación
directa con la vista.
 Controlador: Responde a eventos del usuario invocando peticiones

al modelo y envía la información obtenida a la ‘vista’, el controlador
hace de intermediario entre la ‘vista’ y el ‘modelo’. Suele estar más
relacionado con la ‘vista’ ya que en conjunto tratan los eventos de la
Interfaz Gráfica de Usuario (vista).
 Vista: Es la Interfaz Gráfica de Usuario, normalmente escrita en PHP

embebido en HTML o con ayuda de motores de plantillas como twig
(que será visto más adelante) y con script que se ejecutan del lado del
cliente, estos documentos están diseñados para contener elementos
que permitan la interacción con el usuario.
La estructura del MVC no será implementado como tal, se ha citado debido a

que es un patrón que junto con el de Programación por Capas, comparten
varias características de la arquitectura que realmente será utilizada para el
desarrollo de esta tesis.
P á g i n a | 28
2.10.2 Patrón de Arquitectura de Software Utilizado
En el desarrollo de esta tesis se encuentran implicados 2 principales

patrones de desarrollo y algunas características que no corresponden a ningún
otro, pero que en la práctica es muy común encontrarlos. El primero está definido
por la arquitectura propia de una Aplicación Web la cual es distribuida por 3 Capas,
en la que está involucrado el patrón de Programación por Capas.
El segundo patrón es utilizado de acuerdo con ciertas características que

implementa el framework Symfony, este patrón es el Modelo Vista Controlador,
aunque los mismos desarrolladores del framework sostienen que Symfony no es
un framework MVC, al no tener definida una estructura para representar la parte
del ‘modelo’, sino más bien contar con herramientas opcionales de tipo ORM
(definido más adelante) como Doctrine2 y Propel que pueden utilizarse para
representar a los ‘modelos’ pero estas siguen siendo herramientas opcionales.
“Symfony2 no se define como un framework MVC… Symfony2 realmente

proporciona herramientas para la parte del controlador, la parte vista, pero no para
la parte del modelo… Todo depende de usted para crear el modelo ‘a mano’ o con
cualquier otra herramienta, como un ORM. Por supuesto, existe una estrecha
integración de los ORM más conocidos como Doctrine2 y Propel… Symfony2 es un
framework de HTTP, es decir un framework de Solicitud y Respuesta.” 8
__________________________________________________________________
8 What is Symfony2? By Fabien Potencier [¿Qué es Symfony2? Por Fabien Potencier]. (25 de
Octubre de 2011). Recuperado el 13 de junio de 2013 de
http://fabien.potencier.org/article/49/what-is-symfony2.
P á g i n a | 29
Figura 2.2 Patrón de Arquitectura Hibrido utilizado en el desarrollo de esta tesis.
Como puede observarse parte de la lógica del patrón MVC está contenida
en el Servidor Web mediante el uso del framework, donde el ‘controlador’ escucha
eventos solicitados por el cliente y consulta al ORM, el ORM consulta al Servidor
Datos y posteriormente de acuerdo a la respuesta obtenida devuelve la respuesta
al ‘controlador’ para que este genere una ‘vista’ con ayuda de PHP, HTML y algunos
scripts (como JavaScript) para enviarlos al cliente donde este los visualiza gracias
a un Navegador Web.
P á g i n a | 30
2.11 Ventajas de las Aplicaciones Web
 El problema de gestionar el código en el cliente se reduce drásticamente.

 Evita problemas de inconsistencias en las actualizaciones, ya que no
existen clientes con distintas versiones de la aplicación.
 Una vez teniendo un Navegador Web y una conexión a Internet, no se
necesita comprar ni instalar herramientas adicionales para los clientes.
 La aplicación es independiente de la plataforma, y no es necesario
adaptar el código de la aplicación a cada una de ellas.
 Actualmente muchos dispositivos cuentan con conexión a Internet y por
ende cuentan con un Navegador Web, lo cual ofrece una alta
disponibilidad de la aplicación en cualquier dispositivo.
 Se evita la distribución de copias ilegales del software (piratería).
 Su construcción normalmente se realiza en capas lo que permite migrar
con menor dificultad la lógica de cada capa independiente si es que se
llega a necesitar.
2.12 Inconvenientes de las Aplicaciones Web
 La velocidad de la aplicación además de depender de las tecnologías usadas

para su desarrollo y de la lógica implementada, depende en gran medida de
la calidad de la conexión de Red.
 Su alta disponibilidad se convierte en desventaja ante los usuarios mal
intencionados.
 Depende de una conexión a algún entorno Web.
 No todos los Navegadores muestran de la misma forma los elementos del
diseño de la Interfaz Gráfica de Usuario, así que se deben tomar en cuenta
las restricciones e incompatibilidades de los principales navegadores a la
hora de programar la aplicación del lado del cliente.
CAPÍTULO III
TECNOLOGÍAS PARA LA CONSTRUCCIÓN DE APLICACIONES WEB
P á g i n a | 32
3.1 Introducción
Una aplicación Web requiere ciertas tecnologías para su desarrollo,

implementación y su funcionamiento.
Siguiendo la arquitectura de 3 capas de una Aplicación Web, y como se

mencionó en el capítulo anterior, la primer capa corresponde a la parte de la
aplicación que se ejecutará del lado del cliente mediante un Navegador Web, la
segunda compuesta por el Servidor Web que se encarga de gran parte del
procesamiento de datos y la tercer y última capa correspondiente al Servidor de
Datos encargado del almacenamiento de la información, mediante una base de
datos, por ejemplo.
Para que la comunicación entre las capas se lleve a cabo se necesitan

ciertas tecnologías especiales para cada una de dichas capas y que a
continuación se detallan.
3.2 Capa 1 (Cliente)
3.2.1 Navegador Web
El Navegador Web es una aplicación informática utilizada para localizar,

recuperar y mostrar el contenido en la World Wide Web, incluyendo páginas
web, imágenes, videos y otros elementos multimedia contenidos en documentos
HTML y otros archivos. El Navegador Web es una aplicación de escritorio que
solicita a un Servidor Web los recursos necesarios para ejecutar la Aplicación
Web, el Navegador Web puede ejecutar múltiples Aplicaciones Web.
P á g i n a | 33
“El primer Navegador Web (navegador y editor al mismo tiempo) fue

llamado WorldWideWeb ya que, después de todo, cuando fue escrito en 1990, era
la única manera de ver la web. Mucho más tarde pasó a llamarse Nexus con el fin
de evitar la confusión entre el programa y el espacio de información abstracta (que
ahora se deletrea World Wide Web con espacios).” 1
Los navegadores modernos soportan una combinación de HTML y XHTML

basada en estándares que debe ser dictada en la misma forma por todos los
navegadores. Actualmente existe una gran cantidad de Navegadores Web, que
ofrecen a los usuarios ciertas diferencias que los caracterizan, ya sea mejor
rendimiento, mayor velocidad, seguridad o una interfaz más cómoda, a
continuación los Navegadores Web más notables y sus respectivas fechas de
lanzamiento:
 WorldWideWeb (23 de Febrero de 1991).

 Mosaic (22 de Abril de 1993).
 Netscape Navigator (13 Octubre de 1994).
 Internet Explorer (16 de Agosto de 1995).
 Opera (19 de Abril de 1996).
 Mozilla Navigator (5 de Junio de 2002).
 Safari (7 de Enero de 2003).
 Mozilla Firefox (9 de Noviembre de 2004).
 Google Chrome (2 de Septiembre de 2008).
__________________________________________________________________
1 The WorldWideWeb browser [El Navegador WorldWideWeb]. (s.f.). Recuperado el 03 de junio de
2013 de http://www.w3.org/People/Berners-Lee/WorldWideWeb.html.
P á g i n a | 34
Figura 3.1 Gráfico extraído del sitio Web W3Counter que muestra la participación en el mercado
de los navegadores más dominantes a nivel mundial hasta Abril de 2013 en porcentajes. 2
3.2.2 HTML
Es un lenguaje compuesto de una serie de etiquetas que permiten

definir el contenido y apariencia de las páginas web. Está basado en SGML
pero no se le considera como un subconjunto de él. HTML no es considerado
como un lenguaje de programación pero si como un lenguaje informático. La W3C
es la organización encargada se la estandarización de las etiquetas utilizadas en
HTML. “el idioma de publicación de la World Wide Web.” 3
Versión Utilizada: HTML4 con algunos elementos de HTML 5
__________________________________________________________________
2 W3Counter Global Web Status [W3Counter Estatus Global de la Web]. (Junio de 2013).
Recuperado el 06 de junio de 2013 de
http://www.w3counter.com/globalstats.php?year=2013&month=04.
3 HTML 4.01 Specification [Especificación HTML 4.01]. (24 de diciembre de 1999). Recuperado el
20 de abril de 2013 de http://www.w3.org/TR/1999/REC-html401-19991224/.
P á g i n a | 35
3.2.2.1 HTML5
Es la quinta versión del estándar HTML. Y sus objetivos principales han

sido la mejora del lenguaje con soporte para los dispositivos multimedia
más recientes, manteniéndose legible para los humanos y siendo más
consistente para los analizadores web computarizados (robots o arañas Web).
“El término ‘HTML5’ se utiliza ampliamente como una palabra de moda para
referirse a las tecnologías web modernas.” 4
Algunas de las tecnologías Web a las que se refiere Ian Hickson son CSS,
SVG, WOFF, WebGL entre otras y que además funcionan en conjunto con
JavaScript. HTML 5 también cuenta con APIs como:
 Elemento Canvas que permite una representación dinámica de secuencias

de comandos de formas de 2 dimensiones.
 Reproducción de medios temporizados.
 Ejecución de Aplicaciones Web en modo desconectado.
 Drag and drop (“Arrastrar y Soltar).
 Almacenamiento Web: Almacenamiento par clave-valor similar al
comportamiento de una cookie pero de mayor capacidad.
__________________________________________________________________
4 HTML Standard by Ian Hickson (Google) [El Estándar HTML por Ian Hickson de Google]. (s.f.).
Recuperado el 06 de junio de 2013 http://www.whatwg.org/specs/web-apps/current-
work/#is-this-html5?.
P á g i n a | 36
El uso de HTML5, en el desarrollo de ésta tesis sólo fue aplicado en algunos

elementos, como en los campos de texto de los formularios, que son
generados automáticamente por el framework Symfony para hacer
validaciones cuando detecta que el navegador del cliente soporta esta
tecnología.
3.2.3 CSS
“Cascading Style Sheets (CSS) es un mecanismo sencillo para añadir estilo

(por ejemplo, fuentes, colores, espaciado) a los documentos Web.” 5
Con CSS, es posible cambiar completamente la forma en que los elementos

son presentados por el agente al usuario.
Su aplicación más común es la de las páginas web de estilo escrito en

HTML y XHTML, pero este lenguaje también se puede aplicar a cualquier tipo de
documento XML, como SVG y XUL.
Versión Utilizada: CSS2 con algunos elementos de CSS3
__________________________________________________________________
5 Cascading Style Sheets [Hojas de Estilo en Cascada]. (s.f.). Recuperado el 23 de abril de 2013
de http://www.w3.org/Style/CSS/.
P á g i n a | 37
3.2.4 JavaScript
Es un lenguaje interpretado, basado en objetos (no es un lenguaje

completamente orientado a objetos) y multiplataforma, desarrollado por Netscape
Communications Corporation. Los navegadores de Netscape fueron los primeros
en utilizar JavaScript.
El primer nombre oficial de este lenguaje fue LiveScript y apareció por

primera vez en la versión beta de Netscape Navigator 2.0 en septiembre de 1995,
pero poco después fue rebautizado JavaScript en un comunicado conjunto con
Sun Microsystems el 4 de diciembre de 1995.
Está basado en guiones que son interpretados directamente en el

código HTML cuando el código es transferido al cliente al cargar la página.
JavaScript, desarrollado por Netscape y no tiene relación alguna con Java,

aparte de que sus sintaxis derivan del lenguaje de programación C. En unión con
el Document Object Model de una página web, JavaScript se ha convertido en una
tecnología mucho más importante de lo que pensaron sus creadores originales.
Versión Utilizada: De acuerdo al navegador web

P á g i n a | 38
3.2.4.1 jQuery
Es una librería de JavaScript con dos objetivos principales: la

manipulación de elementos de una página web y facilitar las peticiones Ajax.
Es libre y de código abierto distribuido con una licencia MIT. Es multi-plataforma o
multi-navegador. Fue lanzado en enero de 2006 en Nueva York por John
BarCamp Resig. “Actualmente es utilizado por más del 55% de los 10.000 sitios
web más visitados” 6
jQuery es mantenido por la Fundación jQuery la cual tiene como miembros

a empresas como WordPress, Mediatemple, Blackberry, Adobe, Intel, Github,
entre otras. Además de contar con el respaldo de empresas como Google,
Microsoft y Nokia.
Versión Utilizada: jQuery 1.10.0
Se ha seleccionado jQuery como la librería principal para el manejo de

peticiones Ajax y manipulación de elementos web, ya que su sintaxis resulta
sencilla de aprender y facilita la escritura de código en JavaScript, además
de contar con una documentación muy extensa y una comunidad muy
participativa.
__________________________________________________________________
6 jQuery Usage Statistics [Estadisticas de Uso de jQuery]. (s.f.). Recuperado el 29 de abril de 2013
de http://trends.builtwith.com/javascript/JQuery.
P á g i n a | 39
3.2.4.2 Ajax
AJAX, acrónimo de Asynchronous JavaScript And XML (JavaScript

asíncrono y XML), es una técnica de desarrollo web para crear aplicaciones
interactivas. Ajax proporciona un método por el cual grandes o pequeñas partes
dentro de una página web pueden actualizarse, usando nueva información
obtenida de la red en respuesta a las acciones del usuario. El acceso a los datos
se realiza mediante XMLHttpRequest, objeto disponible en los navegadores
actuales
3.2.5 DOM
Es una Interfaz de Programación de Aplicaciones (API) que proporciona un

conjunto estándar de objetos para representar documentos HTML y XML. La
manipulación del Modelo de Objetos de Documento después de que la página ha
sido enviada al cliente se ha denominado HTML Dinámico (DHTML), para
enfatizar un cambio con respecto a las visualizaciones de HTML estático.
P á g i n a | 40
3.3 Capa 2 (Servidor Web)
3.3.1 Lenguajes de Programación Web
Un lenguaje de programación es un sistema de comunicación que utiliza

una notación o conjunto de símbolos y caracteres combinados entre sí de acuerdo
con una sintaxis ya definida que posibilita la transmisión de instrucciones a un
procesador.
Existen numerosos lenguajes de programación compilados e interpretados que

son empleados para el desarrollo de Aplicaciones Web, entre los que destacan:
 PHP
 ASP/ASP.NET
 Java con sus tecnologías Java Servlets y JavaServer Pages (JSP)
 Perl
 Ruby
 Python
ASP no es un lenguaje de programación en sí mismo, sino una arquitectura de

desarrollo Web en la que se pueden usar distintos lenguajes (por ejemplo VB. NET
o C# para ASP.NET o VBScript/JScript para ASP).
P á g i n a | 41
3.3.1.1 PHP
Es un lenguaje de programación de alto nivel que se ejecuta en el

servidor; una características de este lenguaje es que es gratuito y, por tanto,
cualquier persona interesada en el lenguaje puede utilizarlo de manera gratuita.
“PHP es un lenguaje de scripting de propósito general ampliamente usado

que es especialmente adecuado para el desarrollo web y puede ser embebido en
páginas HTML.” 7
PHP es un lenguaje de secuencias de comandos del servidor, y es una

herramienta de gran alcance para hacer páginas web dinámicas e interactivas.
Es una alternativa libre de ASP de Microsoft.
PHP es usado en más de 244 millones de sitios web y se encuentra

instalado en más 2,1 millones de servidores web.
Creado por Rasmus Lerdorf en 1995, hoy en día este lenguaje es

mantenido por The PHP Group. Originalmente PHP significaba Personal Home
Page, ahora significa Hypertext Preprocessor, en forma de acrónimo recursivo.
__________________________________________________________________
7 PHP: Hypertext Preprocessor. (s.f.). Recuperado el 20 de abril de 2013 de http://www.php.net.
P á g i n a | 42
PHP por muchos años ha sido un lenguaje de programación muy popular,

sin embargo hace tiempo fue juzgado como poco profesional. Un desarrollador de
PHP era estereotipado como un desarrollador independiente, que producía código
barato y de baja calidad. Los ‘verdaderos desarrolladores’ tenían que usar Zope,
ASP y de diversas tecnologías Java.
Luego, en 2005 se produjo un auge de Ruby. Todo el mundo se sorprendió

con la elegancia de este lenguaje de programación y de su framework Ruby on
Rails, Pronto surgieron clones de Ruby on Rails para otros lenguajes como Django
y TurboGears para Phyton, así como también frameworks para PHP.
En 2004 PHP5 fue liberado, ya era orientado a objetos. Las personas

fueron considerando gradualmente a PHP como herramienta profesional y
comenzó a subir su popularidad para el desarrollo de Aplicaciones Web complejas
y no sólo para páginas web sencillas.
Después de unos años, se hizo evidente que Ruby on Rails tenía varias
limitaciones. Una limitación importante es la baja disponibilidad y el alto precio de
los hostings de Ruby, mientras que el alojamiento de PHP resultaba más
económico y abundante en cualquier parte del mundo. Aunado a una gran
comunidad de ansiosos desarrolladores de frameworks para PHP dio lugar a una
revolución informática que restó popularidad a Ruby on Rails mientras los
frameworks para PHP fueron ganando cada vez usuarios.
P á g i n a | 43
Figura 3.2 Gráfico de Netcraft que muestra el crecimiento a nivel mundial de la cantidad de host
que utilizan PHP hasta Enero de 2012. 8
Versión Utilizada: PHP 5.3.8
PHP ha demostrado ser un lenguaje sumamente robusto que permite el

desarrollo de grandes sistemas, lo que ha aumentado su popularidad así
como los servicios que giran alrededor de esta tecnología y que le permiten
tener mayor soporte en comparación a otras tecnologías, aun siendo ésta de
libre distribución, es por estas razones que se seleccionó PHP como
lenguaje principal para el desarrollo de esta tesis.
__________________________________________________________________
8 PHP just grows & grows [PHP sólo crece y crece]. (31 de enero de 2013). Recuperado el 04 de
mayo de 2013 de http://news.netcraft.com/archives/2013/01/31/php-just-grows-grows.html.
P á g i n a | 44
3.3.2 Framework
Un framework es un conjunto de bibliotecas que proporcionan

funciones comunes a toda una clase de aplicaciones. Cada biblioteca por lo
general proporciona una pieza específica de funcionalidad, los frameworks ofrecen
una gama muy amplia de las piezas más utilizadas a menudo por un cierto tipo de
aplicación. En lugar de volver a escribir la lógica de uso común, el programador
puede aprovechar el framework que proporciona la funcionalidad de uso
frecuente, lo que reduce el tiempo necesario para construir una aplicación y
disminuye la posibilidad de introducir nuevos errores.
Básicamente un Framework consta de lo siguiente.
Una caja de herramientas: Un conjunto de componentes de software

prefabricados que son rápidamente integrables. Lo que disminuye el código a
escribir y con menos riesgo de error. Esto también significa una mayor
productividad y la posibilidad de dedicar más tiempo a hacer aquellas cosas que
aportan un mayor valor añadido, como los procesos encargados de las
funcionalidades que realmente le interesan y ayudan al cliente.
Una metodología: Un "esquema de montaje" a seguir para el desarrollo de

las aplicaciones. Permite a los desarrolladores trabajar de forma eficiente y eficaz
en los aspectos más complejos de una tarea, y el uso de las mejores prácticas que
garantiza estabilidad, facilidad de mantenimiento y capacidad de actualización de
las aplicaciones que se desarrollan.
P á g i n a | 45
La principal diferencia entre una librería y un framework es:
 Las librerías son llamadas desde tu código.

 Los frameworks llaman tu código.
Los framewoks proporcionan una estructura sobre la cual se pueden

agregar características y módulos propios de la aplicación a construir, una
librería proporciona un conjunto de herramientas que sirven de ayuda para tu
aplicación, no quiere decir que uno sea mejor que otro, ya que no hay punto de
comparación entre ambos porque están dedicados a objetivos distintos.
Los framework trabajan sobre estándares y buenas prácticas de

programación que son imprescindibles si es que se quiere desarrollar
aplicaciones robustas más tolerantes a fallos y sobre todo escalables,
actualmente no es imposible crear sistemas grandes sin la ayuda de
framewoks, sin embargo no utilizarlos eleva la dificultad, el tiempo y por
ende los costos de desarrollo, tomando en cuenta esas consideraciones se
optó por la utilización de un framework para esta tesis
3.3.2.1 Symfony
Symfony es un framework creado en una empresa francesa de

desarrollo Web llamada Sensio Labs por Fabien Potencier. Primero fue utilizado
para el desarrollo de sus propias aplicaciones y luego en 2005 fue liberado como
un proyecto de código abierto.
P á g i n a | 46
Symfony está basado en el framework Mojavi MVC, con algunas

influencias inevitables de Ruby on Rails. También YAML para la configuración
y el modelado de datos. Ofrece una solución de Mapeo Objeto-Relacional (ORM)
predeterminado llamado Doctrine. Hoy Symfony es uno de los frameworks Web
líderes. Dispone de una gran comunidad activa y una gran cantidad de
documentación principalmente libros electrónicos gratuitos.
Versión Utilizada: Symfony 2.2.1
Symfony cuenta con una serie de tecnologías y técnicas que permitirán

un desarrollo más escalable del caso práctico de esta tesis, entre ellas
está el patrón Modelo Vista Controlador, Twig, Doctrine, entre otros. También
cuenta con una amplia documentación, una comunidad muy participativa
además de ser una tecnología gratuita.
3.3.3 Servidor Web
Es una aplicación informática que realiza conexiones con el cliente

utilizando el protocolo HTTP mediante el puerto 80, este protocolo opera en la
capa de aplicación del modelo OSI. Algunos de los Servidores Web más utilizado
es Internet son:
 Apache HTTP Server / Apache

 IIS / Microsoft
 nginx / NGINX Inc
 GWS / Google
P á g i n a | 47
Las estadísticas de la cuota de mercado de los servidores de la Web en

Internet realizada por Netcraft hasta abril de 2013 muestra la siguiente gráfica:
Figura 3.3 Gráfico de Netcraft que muestra el uso mundial de los Servidores Web más
populares hasta abril de 2013.9
__________________________________________________________________
9 April 2013 Web Server Survey [Encuesta de Servidores Web de Abril de 2013]. (02 de abril de
2013). Recuperado el 29 de abril de 2013 de
http://news.netcraft.com/archives/2013/04/02/april-2013-web-server-survey.html.
P á g i n a | 48
3.3.3.1 Servidor HTTP Apache
El Servidor HTTP Apache, conocido también como simplemente Apache, es

un Servidor Web de código abierto que destaca por jugar un papel clave en el
crecimiento inicial de la World Wide Web. Apache httpd ha sido el servidor web
más popular en Internet desde abril de 1996. En 2009, se convirtió en el primer
Servidor Web en superar los 100 millones de sitio web.
Apache es desarrollado y mantenido por una comunidad abierta de

desarrolladores bajo el auspicio de la Fundación de Software Apache. La
aplicación está disponible para una amplia variedad de sistemas operativos,
incluyendo Unix, FreeBSD, Linux, Solaris, Novell NetWare, OS X, Microsoft
Windows y OS / 2. Lanzado bajo la licencia Apache.
Este servidor web es redistribuido como parte de varios paquetes propietarios

de software, incluyendo la base de datos Oracle y el IBM WebSphere application
server. Mac OS X integra Apache como parte de su propio servidor. También es
incluido con Novell NetWare 6.5, donde es el servidor web por defecto, y en
muchas distribuciones Linux.
El servidor de base puede ser extendido con la inclusión de módulos externos

entre los cuales se encuentran:
 mod_cband - Control de tráfico y limitador de ancho de banda.

 mod_perl - Páginas dinámicas en Perl.
 mod_php - Páginas dinámicas en PHP.
 mod_python - Páginas dinámicas en Python.
P á g i n a | 49
 mod_rexx - Páginas dinámicas en REXX y Object REXX.

 mod_ruby - Páginas dinámicas en Ruby.
 mod_mono - Páginas dinámicas en Mono
 mod_security - Filtrado a nivel de aplicación, para seguridad.
Versión Utilizada: HTTP Apache Server 2.2.21
Independientemente de su popularidad, la elección de esta tecnología

también está basada en su tipo de distribución así como la documentación
con la que cuenta, el soporte de distintas plataformas y costos económicos
de alojamiento.
3.4 Capa 3 (Servidor de Datos)
3.4.1 Bases de Datos
Una Base de Datos es un conjunto de información relacionada que se

encuentra agrupada en una computadora siguiendo una estructura. Una base de
datos constituye la representación abstracta de un problema del mundo real así
como los datos de información acerca del problema en cuestión.
P á g i n a | 50
3.4.2 SQL
El Lenguaje de Consulta Estructurado SQL (por sus siglas en inglés

Structured Query Language) es un lenguaje declarativo estándar para acceder
a bases de datos en un Sistema Gestor de Bases de Datos Relacionales
(RDBMS). Consiste en un lenguaje de definición de datos y un lenguaje de
manipulación de datos.
“SQL relativamente es un lenguaje de ‘alto nivel’. Un solo comando puede

crear una tabla con tantas columnas como desee… Las operaciones que pueden
tardar decenas, o cientos, de líneas de código en lenguajes como C o Java
pueden ejecutarse en un solo comando SQL.” 10
SQL fue desarrollado inicialmente en IBM por Donald D. Chamberlin y

Raymond F. Boyce a principios de 1970. Se convirtió en un estándar de la
American National Standards Institute (ANSI) en 1986, y de la Organización
Internacional de Normalización (ISO) en 1987.
__________________________________________________________________
10 IBM solidDB 6.3 and IBM solidDB Universal Cache 6.3 Information Center. (s.f.). Recuperado el
09 de junio de 2013 de
http://publib.boulder.ibm.com/infocenter/soliddb/v6r3/index.jsp?topic=/com.ibm.swg.im.solid
db.sql.doc/doc/tables.rows.and.columns.html.
P á g i n a | 51
3.4.3 Sistema Gestor de Bases de Datos
Un Sistema Gestor de Base de Datos (SGBD) es una colección de

programas que manejan la estructura de la base de datos y los controles de
acceso a la información almacenada en la misma.
Su objetivo es servir de interfaz entre la base de datos, el usuario y las

aplicaciones y se compone de un lenguaje de definición de datos, un lenguaje de
manipulación de datos y de un lenguaje de consulta. Algunos SGB:
Tipos de Sistemas Gestores de Bases de Datos

Número de Usuarios Localización de Datos Utilización de Datos
Multiusuario
SGBD Usuario XML
Grupo Centralizado Distribuido Operacional Analítica
Simple
de Empresarial
Trabajo
MS
X X X X
Access
MS
SQL X X X X X X X X
Server
IBM
X X X X X X X X
DB2
MySQL X X X X X X X X
Oracle X X X X X X X X
RDBMS
Figura 3.4 Tabla comparativa de algunos los tipos de SGBD más utilizados
P á g i n a | 52
“En cierto sentido, una base de datos es similar a un armario electrónico

muy bien organizado en el que un potente software (SGBD) ayuda a gestionar los
contenidos del gabinete.” 11
3.4.3.1 MySQL
Es un Sistema Gestor de Base de Datos Relacional (RDBMS) de código

abierto. Lleva el nombre de la hija co-fundador Michael Widenius, My y las siglas
SQL del Inglés de Lenguaje de Consulta Estructurado.
“Los datos en MySQL se almacenan en tablas. Una tabla es una colección

de datos relacionados, y que se compone de columnas y filas.” 12. Está basado en
el álgebra relacional y el cálculo relacional de tuplas.
 Es un sistema de base de datos que se ejecuta en el servidor

 Es ideal para aplicaciones pequeñas y grandes
 Es muy rápido, fiable y fácil de usar
 Soporta el estándar SQL
 Compila en un número de plataformas
 Es gratuito para descargar y usar
 Es desarrollado, distribuido y mantenido por Oracle Corporation
__________________________________________________________________
11 Coronel, Morris, Rob. (2013). Database Systems: Design, Implementation, and Management,
Course Technology [Bases de Datos: Diseño, Implementación y Gestión, Curso de
Tecnología]. Estados Unidos de América: Cengage Learning. p 8.
12 PHP MySQL Introduction [Introducción a PHP MySQL]. (s.f.). Recuperado el 26 de abril de 2013
de http://www.w3schools.com/php/php_mysql_intro.asp.
P á g i n a | 53
MySQL también es utilizado en algunos de los componentes o servicios de

distintos sitios web, como Wikipedia, Google, Facebook, Twitter, Flickr, y
YouTube.
Versión Utilizada: MySQL 5.5.16
MySQL es la base de datos más popular del mundo, es escalable y al igual

que PHP cuenta con documentación muy amplia y herramientas que permite
un desarrollo más ágil.
3.4.4 Modelos de Datos
Es un conjunto de conceptos y reglas que permite describir la estructura

de datos de una Base de Datos, las restricciones de Integridad, es decir, las
condiciones que deben cumplir los datos para relacionarse, y las operaciones de
manipulación de datos como agregado, borrado y modificación.
Su clasificación pude ser vista desde los siguientes 3 aspectos:
 Modelos de datos Conceptuales: Son aquellos orientados a la descripción de

estructuras de datos y restricciones de integridad.
 Modelos de Datos Lógicos: Son aquellos orientados a las operaciones y
usualmente están implementaos en algún Sistema Gestor de Bases de Datos
(SGBD). Algunos Modelos de datos lógicos son:
o Modelo jerárquico
o Modelo en red
o Modelo relacional
 Modelos de Datos Físicos: Se trata de estructuras de datos a bajo nivel
implementadas por los SGBDs como los Arboles, las estructuras Hash, etc.
P á g i n a | 54
3.4.4.1 Modelo Relacional
El modelo relacional gestiona los datos acomodándolos en tablas

separadas pero al mismo tiempo están interconectadas (relacionadas). Está
basado en lógica de predicados y en la teoría de conjuntos. El modelo lógico, con
objetos tales como bases de datos, tablas, vistas, filas y columnas, ofrece un
entorno de programación flexible. Sus bases fueron postuladas en 1970 por Edgar
Frank Codd, de los laboratorios IBM.
“En 1979, el CEO de Oracle, Larry Ellison, trabajo junto con investigadores
de IBM y de la Universidad de California en Berkely, y lanzó el primer Sistema
Gestor de Bases de Datos comerciales (SGBD) basado en el Modelo Relacional.
Las Bases de Datos Relacionales (SGBDR) irrumpieron en la escena en la década
de 1980 y rápidamente dominaron el mercado de bases de datos.” 13
Algunos de sus componentes principales son:
 Esquema: Contiene la definición de una estructura (tablas o relaciones),

contiene el tipo de información que almacenara en ella, es decir, contiene
los metadatos de la base de datos.
 Instancia: Es una aplicación de un esquema, podría verse como un objeto
que es producto de un clase (esquema) , y está constituida por el contenido
de una tabla o como un subconjunto de información de acuerdo a la
consulta requerida.
__________________________________________________________________
13 Coronel, Morris, Rob. (2013). Database Systems: Design, Implementation, and Management,
Course Technology [Bases de Datos: Diseño, Implementación y Gestión, Curso de
Tecnología]. Estados Unidos de América: Cengage Learning. p 3.
P á g i n a | 55
Sus principales ventajas son:
 Sus herramientas y mecanismos garantizan evitar la duplicidad de registros,

a través de campos claves también llamados llaves.
 Integridad Referencial, ser refiere a que una fila o registro esté relacionada
siempre con otras entidades válidas. Esto tiene como resultado que dichos
datos sean correctos, sin repeticiones, datos perdidos o relaciones mal
hechas.
 Permite que la normalización de los datos sea más comprensible y
aplicable.
Las tendencias apuntan hacia tecnologías NoSQL que presumen de ser más
flexibles, de ofrecer mayor escalabilidad y soporte de concurrencia, a
diferencia de las bases de datos relacionales, sin embargo sus servicios de
alojamiento son contados y resultan más costosos. Además los SGBDR
como MySQL son suficientemente escalables y rápidos como para atender
las necesidades de grandes sistemas como el desarrollado en esta tesis.
3.4.4.2 Modelo Entidad-Relación
Es una herramienta o un modelo de datos conceptual que ayuda a

representar las entidades relevantes de un sistema así como sus
interrelaciones y sus atributos. Es básicamente una representación gráfica (con
ciertas características lógicas) que es utilizada frecuentemente a la par del Modelo
Relacional. El Modelo E-R como también es llamado por sus siglas en inglés
Entity-Relashionship Model consta de:
P á g i n a | 56
 Entidad: Representa a un objeto del mundo real (persona, casa,

animal, etc).
 Atributos: Son las características o propiedades que definen a una
entidad.
 Relación: Es la dependencia entre entidades, representa su relación
y de qué manera están asociadas entre ellas.
Las relaciones entre entidades están sujetas a ciertas restricciones, como lo

son la correspondencia de cardinales:
 Uno a Uno.
 Uno a Muchos.
 Muchos a Muchos.
3.4.4.3 Diagrama Entidad-Relación
Estos diagramas sirven para dar una idea generalizada de la estructura de la

base de datos, a continuación se describe como tienen que ser representados los
objetos más utilizados.
 Entidades: Son representadas con el nombre de la entidad dentro de un

rectángulo.
 Atributos: Se representan mediante un círculo o elipse con el nombre del
atributo en el interior.
 Relaciones: Existen distintos tipos de notación para las relaciones, lo más
común es utilizar un rombo que une mediante líneas a las entidades que
relaciona.
P á g i n a | 57
3.4.5 ORM
El Mapeo Objeto-Relacional (más conocido por su nombre en inglés,

Object-Relational mapping, o sus siglas O/RM, ORM, y O/R mapping) es una
técnica de programación que permite convertir datos entre tipos incompatibles, en
los lenguajes orientados a objetos, crea el efecto de una base de datos orientada
a objetos virtual, en otras palabras convierte datos de una base de datos
relacional a un lenguaje de programación orientado a objetos y viceversa.
Uno de los ORM más utilizado es Hibernate, que surgió para Java y ha sido
llevado al uso del framework .NET con la versión NHibernate. Para PHP existe un
ORM llamado Doctrine y que cuenta con integración con el framewok Symfony.
3.4.5.1 Doctrine
Es un conjunto de librerías de las que destaca un ORM. Una de sus

características clave es la opción para escribir consultas a la base de datos en
dialecto SQL orientado a objetos llamado Doctrine Query Language (DQL).
Las entidades en Doctrine son objetos ligeros de PHP y pueden persistirse

mediante un administrador de entidades. Ejemplo: Persistencia un objeto con DQL
para Doctrine 2.
P á g i n a | 58
1 <?php
2 // Crear instancia de usuario
3 $usuario = new Usuario();
4 // Colocar nombre
5 $usuario->nombre = “john”;
6 // Colocar password
7 $usuario->password = “12345”;
8 // Persistir objeto usuario ya con las propiedades que se
colocaron
9 $entityManager->persist($usuario);
10 // Se hace una ‘limpieza’ del administrador de entidad
para indicar que ha terminado
11 $entityManager->flush();
12 // Impresión en pantalla del id de usuario se encuentra
guardado
13 echo "El usuario con id $usuario->id ha sido guardado.";
14 ?>
Figura 3.5 Ejemplo de persistencia de un objeto DQL con Doctrine 2
Versión Utilizada: Doctrine 2.2.3
3.5 Otras tecnologías de desarrollo
3.5.1 UML
El Lenguaje de Modelado Unificado o UML (Unified Modeling Language) es

un lenguaje de modelado estandarizado que mediante técnicas de notación
gráfica permite visualizar, especificar, construir y documentar sistemas de
software. Surgió a finales de la década de 1980. Cuenta con respaldo del OMG
(Object Management Group).
P á g i n a | 59
“El lenguaje de modelado es una notación (principalmente gráfica) de que

se valen los métodos para expresar los diseños” 14
La utilización de UML resulta de gran ayuda para el desarrollo de software

ya que mediante diagramas proporciona una visión acerca de cómo es el
funcionamiento de cierto modulo en el sistema, sin embargo, para el efecto
de esta tesis se ha seleccionado una metodología que se centra más en
el funcionamiento del sistema en sí que en una laboriosa
documentación de planificación y de diseño, a este tipo de metodología
se le conoce como Metodología Ágil (la cual será vista más a detalle en los
siguientes capítulos) y aunque no está ausente de documentación ésta es
sumamente ligera y simple.
UML cuenta con estándares que permiten describir un modelo que incluye
aspectos conceptuales tales como proceso de negocio, funciones del
sistema expresiones de lenguajes de programación y esquemas de bases de
datos.
UML no es un lenguaje de programación, es un lenguaje para representar

mediante diagramas los artefactos o módulos del sistema que sirven de
documentación.
__________________________________________________________________
14 Fowler M., Scott K. (1999). UML gota a gota (Jaime González V., David Morales Peake trad.).
Estados Unidos Mexicanos: Pearson.p.1.
P á g i n a | 60
3.5.2 Twig
Es un motor de plantillas para el lenguaje de programación PHP.

Básicamente permite la reducción y optimización de código escrito en PHP
embebido en páginas HTML. Es de código abierto y distribuido bajo una licencia
BSD. Fue desarrollado por Fabien Potencie Su sintaxis se origina a partir de
plantillas Jinja y Django.El framework Symfony2 viene con un soporte integrado
para twig como su motor de plantillas por defecto.
Twig es utilizado para desarrollar los scripts correspondientes a las

‘vistas’ de acuerdo con el Modelo Vista Controlador (MVC), las cuales reciben
y envían datos a los controladores. Twig proporciona una sintaxis propia que sólo
el o los desarrolladores ven de esa forma, el motor convierte el código para que el
cliente lo vea como un HTML común y este pueda se mostrado en un Navegador
Web.
Comparación de PHP puro usado como motor de plantillas vs Twig:
PHP:
1 <ul id="navegacion">
2 <?php
3 foreach ($arreglo as $elemento) {
4 $class = ($elemento->id == 1) ? "activado" : "";
5 echo "<li class='$class'><a href='$elemento-
>ref'>$elemento- >nombre</a></li>";
6 }
7 ?>
8 </ul>
Figura 3.6 Ejemplo de plantilla HTML usando PHP ‘puro’.

P á g i n a | 61
Twig:
1 <ul id="navegacion">
2 {% for elemento in arreglo %}
3 <li class="{{ (elemento.id == 1) ? ’activado’
}}"><a href="{{ elemento.ref }}">{{ elemento.nombre
}}</a></li>
4 {% endfor %}
5 </ul>
Figura 3.7 Ejemplo de plantilla HTML usando el motor de plantillas Twig.
Más allá de ahorrar líneas de código Twig facilita el trabajo de los

programadores al realizar un auto escapado de la información mostrada, lo que
ofrece mayor seguridad ante descuidos de los programadores. Uno de los
objetivos de la Twig es ser lo más rápido posible. Para lograr la mejor velocidad
posible, Twig compila plantillas a simple código PHP optimizado que normalmente
es más veloz que las plantillas escritas por el propio programador en PHP.
Versión Utilizada: Twig 1.0
3.5.3 JSON
JSON (del inglés JavaScript Object Notation) Es un formato de

intercambio de datos ligero. JSON es soportado por distintos lenguajes de
programación entre ellos se incluye ActionScript, C, C++, C#, ColdFusion,
Common Lisp, Delphi, E, Eiffel, Java, JavaScript, ML, Objective-C, Objective
CAML, Perl, PHP, Python, Rebol, Ruby, Lua y Visual FoxPro.
P á g i n a | 62
“JSON es para almacenar e intercambiar información de texto. Al igual que

XML... es más ligero que XML y más fácil y más rápido para analizar” 15 JSON se
basa en dos estructuras:
 Colección nombre/valor. En varios lenguajes, esto es similar a un objeto,

registro, estructura, diccionario, tabla hash, lista con clave, o una matriz
asociativa.
 Lista ordenada de valores. En la mayoría de los lenguajes, esto se similar
a un arreglo, matriz, vector, lista o secuencia.
Ejemplo de JSON
1 {
2 "id": 987387618927373,
3 "nombre": "Juan",
4 "apellidos": "Perez Lopez",
5 "direccion": {
6 "calle": "Av. Arbol",
7 "colonia": "San Martin",
8 "estado": "Distrito Federal"
9 },
10 "telefono": [
11 {"ubicacion": "casa", "numero": "5534231090"},
12 {"ubicacion": "trabajo", "numero": "5569100893"}
13 ]
Figura 3.8 Ejemplo de JSON.
Los cuadros comparativos de las tecnologías seleccionas y otras

tecnologías disponibles para desarrollo de aplicaciones Web pueden ser
consultadas en el Anexo A Tablas Comparativas de Tecnologías
__________________________________________________________________
15 JSON Tutorial. (s.f.). Recuperado el 12 de junio de 2013 de http://www.w3schools.com/json/
CAPÍTULO IV
SEGURIDAD EN APLICACIONES WEB
P á g i n a | 64
4.1 Introducción
La protección, confianza y la seguridad en una Aplicación Web son piezas

fundamentales en el buen funcionamiento y el éxito de la misma, puesto que la
información de los usuarios se encuentra alojada en un lugar remoto.
La propia arquitectura de una Aplicación Web facilita su acceso a una

cantidad muy grande de usuarios para hacer llegar hasta ellos todos su beneficios
y generar una retroalimentación, sin embargo esa gran ventaja también representa
sus inconvenientes, no todos los usuarios tienen las mismas intenciones o
pretensiones ante el sistema y sobran diversas justificaciones que tienen cada uno
de ellos para intentar burlar, vulnerar o atacar al sistema, es por eso que en el
proceso de desarrollo se tomen en cuenta la mayor cantidad de ‘puntos flacos’ por
los cuales los usuarios mal intencionados pudieran llegar a vulnerar el sistema.
“Seguridad de las Aplicaciones Web debe ser abordada a través de los

niveles y en múltiples capas. Una debilidad en cualquier capa hace que la
aplicación sea vulnerable a los ataques.” 1
__________________________________________________________________
1 Improving Web Application Security: Threats and Countermeasures [Mejorando la seguridad de
las Aplicaciones Web: Amenazas y Contramedidas]. (s.f.). Recuperado el 05 de junio de
2013 de http://msdn.microsoft.com/en-us/library/ms994921.aspx.
P á g i n a | 65
Figura 4.1 Panorama general de aspectos de seguridad básica en una Aplicación Web.
Cabe mencionar que una gran cantidad de fallas de seguridad se

encuentran a nivel aplicación y la mayoría de ellos se debe a errores
causados por una mala programación, por una escritura defectuosa de código
por parte de los programadores.
P á g i n a | 66
Existen 4 enfoques en los cuales abordan la seguridad global de cualquier tipo

de sistema de información:
 Prevención. Evitar un problema de seguridad, en primer lugar, se eliminan

las posibles vulnerabilidades y amenazas.
 Detección. Se comparan los riesgos considerados aceptables con las
acciones que se observan, y se ejecuta un proceso de notificación para que
el personal de seguridad detecte las inconsistencias existentes.
 Forense. La ciencia forense digital se define como el uso de métodos
científicamente obtenidos y probados que conducen a la preservación,
recolección, validación, identificación, al análisis, a la interpretación,
documentación y presentación de evidencias de fallos en un sistema a
partir de fuentes digitales, con el propósito de reconstruir los eventos
encontrados clasificados como delitos.
 Respuesta y actuación. Consiste en responder a una brecha detectada.
La respuesta pude ser reactiva, ante alguna acción que se haya producido,
o proactiva, anticipándose a cualquier fallo que pueda suceder.
La mejor manera posible para centrarse en la seguridad, como desarrollador,

es comenzar a pensar como un hacker. Examinar los mismos métodos que los
atacantes utilizan para vulnerar y romper los sitios web, y utilizar esas mismas
prácticas para prevenir los ataques.
P á g i n a | 67
4.2 Cross-Site Scripting (XSS)
XSS, del inglés Cross-site scripting es un tipo de vulnerabilidad que permite la

inyección de código malicioso en páginas web visitadas por otros usuarios,
abarca cualquier ataque que permita ejecutar código de ‘script’ como VBscript y
JavaScript. Existen 2 tipos de ataque XSS y son:
 Directa: Consiste en invadir código HTML mediante la inclusión de

etiquetas <script> y <frame>.
 Indirecta: Consiste en modificar valores que la aplicación web utiliza para
pasar variables entre dos páginas.
“Son ataques dirigidos, por lo tanto, contra los uaurios y no contra el Servidor
Web. Mediante ‘Cross-Site Scripting’, un atacante puede realizar operaciones o
acceder a información en un Servidor Web en nombre del usuario afectado,
suplantando su identidad.” 2
Actualmente el XSS es considerado como una vulnerabilidad que está

desapareciendo, ya que los navegadores modernos han puesto en práctica
medidas básicas para prevenir ataques de este tipo, lo cual ofrece mayor
protección a las Aplicaciones Web, sin embargo no hay que pasar por alto
medidas de seguridad que prevengan a nivel aplicación este tipo de ataques ya
que según el informe de vulnerabilidad en la Web en 2013, realizado por la
empresa Cenzic, muestra que la XSS es la vulnerabilidad más común.
__________________________________________________________________
2 Gómez Vieites A. (2007). Enciclopedia de la Seguridad Informática. México: Alfaomega.p 145.
P á g i n a | 68
INFORME DE LAS TENDENCIAS EN VULNERABILIDAD

DE LAS APLICACIONES: 2013
Acceso a Directorios
Configuración de no autorizados 2%
Servidor Web 3%
Ejecución de
Código Remoto 5% XSS 26%
Versión de Servidor
Web 5%
Inyección SQL 6%
CSRF 8%
Autenticación y
Autorización 13%
Administración de Fuga de
Sesiones 16% Información 16%
Figura 4.2 Gráfica de los resultados obtenidos del informe de las tendencias en vulnerabilidad de
las aplicaciones en 2013 realizado por Cenzic.
“El 26% del total, Cross Site Scripting (XSS) fue la vulnerabilidad más frecuente en
aplicaciones probadas en 2012. Sorprendentemente, las vulnerabilidades XSS
aumentaron significativamente en 2012 respecto a 2011.” 3
__________________________________________________________________
3 Application Vulnerability Trends Report: 2013 [Informe de las Tendencias en Vulnerabilidad de
las Aplicaciones: 2013]. (2013). Recuperado el 05 de junio de 2013 de
P á g i n a | 69
http://info.cenzic.com/rs/cenzic/images/Cenzic-Application-Vulnerability-Trends-Report-
2013.pdf.
Protección contra XSS
Como se mencionó anteriormente los Navegadores Web modernos ya

ofrecen cierto grado de protección contra este tipo de ataques y a pesar de esas
medidas resulta insuficiente para proteger a las aplicaciones, es por eso que para
ofrecer un mayor grado de protección son necesarias algunas funciones de
escapado de cadenas de texto HTML. PHP cuenta con una función llamada
htmlspecialchars() que convierte la cadena de texto.
Ejemplo:
1 $new = htmlspecialchars("<a href='test'>Test</a>",ENT_QUOTES);

2 echo $new;
// El resultado sería:
<a href='test'>Test</a>
Figura 4.3 Escapado de caracteres con htmlspecialchars de PHP
El framewok Symfony realiza el escapado de este tipo de cadenas de texto

de manera automática mediante el uso del motor de plantillas Twig. Al momento
de recibir o enviar la información mediante Vistas.
Protección Utilizada: Symfony, Twig, Navegador Web Actualizado y Lógica

P á g i n a | 70
4.3 Cross-Site Request Forgery (CSRF)
Los ataques de este tipo permiten al usuario mal intencionado enviar

peticiones HTTP a voluntad desde la máquina de la víctima, el atacante debe
conocer el formato de la URL para modificar los parámetros enviados a través de
métodos de tipo GET, comúnmente insertando la URL modificada dentro de una
etiqueta de imagen de esta forma:
1. <img src =
"http://webvulnerable.org/buscar.php?param=valor&param2=valor
" />
Figura 4.4 Ejemplo común ocultar una URL para hacer un ataque CSFR
Protección contra CSRF
El framework Symfony provee protección contra CSRF la cuál funciona

añadiendo un campo oculto al formulario (por defecto el campo se llama _token).
Esto garantiza que es el usuario real el que está enviando los datos del formulario.
Symfony valida automáticamente la presencia y la validez de este token que será
añadido automáticamente en la plantilla utilizando la función form_rest(), que
garantiza que se incluyan todos los campos definidos por el formulario.
P á g i n a | 71
Por defecto la protección CSRF esta activada, en caso de necesitar

desactivarla se establece en la opción csrf_protection del formulario a false.
Ejemplo:
1 <input type="hidden" id="q_pvbundle_usertype__token"

name="q_pvbundle_usertype[_token]"
value="ee7b81b0c874b3fd94257f520e60cf82697d0c62" />
Figura 4.5 Protección contra CSFR mediante un token provisto por Symfony
Protección Utilizada: Symfony, Navegador Web Actualizado y Lógica
4.4 Inyección SQL
La inyección de código SQL es una de las vulnerabilidades más comunes

en aplicaciones PHP y se trata de una infiltración de código aprovechando una
falla de programación relacionada con el escape y validación de entradas
para realizar consultas a la base de datos.
Básicamente cuando un usuario escribe código SQL en algún

formulario y este logra ser ejecutado como tal, se dice que se ha inyectado
código SQL. El usuario malintencionado debe tener alguna noción o intuición
sobre la estructura de la base de datos y de esta forma aprovechar escribiendo
una sentencia SQL que puedan comprometer la seguridad de la base de datos.
P á g i n a | 72
“Este tipo de ataques se podrían evitar filtrando los datos enviados po el

usuario antes de que éstos sean procesados por el servidor, para evitar que se
puedan incluir y ejecutar textos que representen nuevas sentencias SQL.“ 4
No es recomendable utilizar consultas SQL basadas directamente en

cadenas de texto que el usuario pueda enviar a través del navegador, éstas
cadenas de texto se deben construir a manera de consultas en el servidor con
sentencias preparas y procedimientos almacenados, que proporcionen
encapsulación a la información enviada, esto puede solucionarse mediante la
creación de ‘modelos’ en el patrón MVC o el uso de ORMs.
Ejemplo:
Suponiendo que se tiene un inicio de sesión simple, y para verificar la

existencia del registro tenemos que realizar una consulta a la base de datos de la
siguiente forma:
1 $query = "SELECT * FROM ÙSUARIO` WHERE `nombre ` = ' " +

$nombreDeUsuario + " ' ; ";
Figura 4.6 Ejemplo de consulta a base de datos sin protección de escapado de caracteres.
__________________________________________________________________
4 Gómez Vieites A. (2007). Enciclopedia de la Seguridad Informática. México: Alfaomega.p 145.
P á g i n a | 73
El usuario mal intencionado podría colocar en el formulario de usuario algo como

esto:
Figura 4.7 Ejemplo de Inyección SQL en el campo de un formulario.
Esa cadena completaría la sentencia quedando de la siguiente forma:
1 SELECT * FROM ÙSUARIO` WHERE `nombre` = 'Ana';

2 DROP TABLE ÙSUARIO`;
3 SELECT * FROM ÀDMIN` WHERE `password` LIKE '%';
Figura 4.8 Cadena de texto resultante que es interpretado como una instrucción SQL
P á g i n a | 74
El resultado de dicha ejecución terminaría eliminando la tabla USUARIO

y además devolviendo la información de todos los registro de la tabla ADMIN
en el campo password y si este no se encuentra encriptado el usuario
malintencionado podría saber exactamente el password de todos los
administradores.
Protección contra Inyección SQL
Una forma de solucionar esto en PHP es utilizando función para MySQL

llamada mysql_real_escape_string:
1 $query = mysql_query("SELECT * FROM ÙSUARIO` WHERE `nombre`

= \"" . mysql_real_escape_string($nombreDeUsuario) . "\"");
Figura 4.9 Escapado de una cadena de texto recibida desde un formulario con
mysql_real_escape_string de PHP
Symfony también ofrece protección contra este tipo de ataques y lo hace

mediante la integración del ORM Doctrine, la abstracción de la Base de Datos
Relacional a manera de Objetos lleva consigo ciertas funcionalidades que impiden
la ejecución de código SQL escrito por el usuario como parte del script SQL
original escrito en el Servidor Web.
P á g i n a | 75
La protección por parte de Doctrine se realiza mediante su lenguaje DQL y

más en específico con el uso del método setParameter que puede utilizarse de 2
formas distintas:
Sentencias por nombre:
1 $dql = "SELECT `telefono` FROM ÙSUARIO` WHERE

ÙSUARIO`.`nombre` = :nombre";
2 $query = $em->createQuery($dql);
3 $query->setParameter("nombre", $_GET['nombreDeUsuario']);
4 $data = $query->getResult();
Figura 4.10 Ejemplo de protección contra inyección SQL con Doctrine y su método setParameter
con sentencias por nombre.
Sentencias por posición:
1 $dql = "SELECT `telefono` FROM ÙSUARIO` WHERE

ÙSUARIO`.`nombre` = ? 1";
2 $query = $em->createQuery($dql);
3 $query->setParameter(1, $_GET['nombreDeUsuario']);
4 $data = $query->getResult();
Figura 4.11 Ejemplo de protección contra inyección SQL con Doctrine y su método setParameter
con sentencias por posición.
Protección Utilizada: ORM Doctrine y Lógica de Programación

P á g i n a | 76
4.5 Encriptación de Datos
La exposición de datos importantes es una de las preocupaciones más

comunes de las bases de datos, como por ejemplo, números de tarjetas de
crédito, contraseñas incluso números telefónicos. A estos y otros datos
importantes se les llama datos sensibles o información sensible.
Es necesario aplicar técnicas, que alteren la representación original de

la información sensible, mediante cifrado, para hacerlos ininteligibles a los
intrusos que logren interceptar dicha información.
“Una vez un atacante gana acceso directamente a su base de datos (sobre

pasando el servidor web), los datos sensibles podrían ser divulgados o mal
utilizados, a menos que la información esté protegida en la base de datos por sí
misma. Encriptando los datos es una buena forma de mitigar esta amenaza, pero
muy pocas bases de datos ofrecen este tipo de encripción de datos” 5
Si es que algún usuario lograra burlar la seguridad a nivel aplicación y

entrar a la base de datos ya sea mediante alguna técnica como inyección SQL o
mediante Ingeniería Social, datos importantes quedaría expuestos. Una buena
recomendación es la encriptación de los datos más sensibles, de manera que si la
base de datos es comprometida el atacante no pueda descifrar la información. Un
ejemplo de esta técnica es almacenar las contraseñas de usuario convertidas a
MD5.
__________________________________________________________________
5 Modelo de almacenamiento encriptado. (s.f.). Recuperado el 14 de junio de 2013 de
http://php.net/manual/es/security.database.storage.php.
P á g i n a | 77
Existen dos maneras generales de realizar la encriptación de información

sensible, la primera de ellas se utiliza encriptando al momento de almacenarse y
desencriptando al momento de mostrar la información al usuario, la segunda es
utilizada cuando la información no requiere el uso de su representación real, de
esta manera se encripta al momento de ser almacenado y así permanece
(ejemplo: contraseña).
Encriptación
Utilizando funciones de PHP para encriptar como md5() o cytp() puede

realizarse la protección de datos sensibles almacenados en la Base de Datos.
Symfony provee sus propias librerías para realizar el encriptado de información.
En el desarrollo de esta tesis las contraseñas de los usuarios son encriptadas de
una manera muy similar a la siguiente:
1 // Colocar salt a una entidad de usuario utilizando el

‘tiempo’ actual
2 $usuario->setSalt(time());
3 // Crear objeto encriptar
4 $encriptar = new MessageDigestPasswordEncoder('sha512', true,
3);
5 // Encriptar contraseña mesclada con salt
6 $encPassword = $encriptar->encodePassword($password,
$usuario->getSalt());
7 // Colocar password encriptado a la entidad usuario
8 $entity->setPassword($encPassword);
Figura 4.12 Ejemplo de encriptación de una contraseña utilizando Symfony.

P á g i n a | 78
En la primer línea de código se coloca un salt que es una cadena aleatoria

que ayudará a realizar la encriptación de la información a manera de ‘mezcla’, este
salt puede ser cualquier cadena, para este ejemplo se utilizó el método time(), que
devuelve un número que indica la fecha y hora del momento en que se manda a
llamar. El salt debe almacenarse en la base de datos, en este ejemplo la tabla
usuario debe tener un campo llamado salt.
En la segunda línea de código se crea un objeto con el método

MessageDigestPasswordEncoder() este objeto recibe 3 parámetros siendo el
primero el que indica que tipo de algoritmo utilizará para la encriptación, en este
caso es el algoritmo “sha512”, el segundo parámetro indica si se desea utilizar
base 64 o no, el último parámetro indica el número de iteraciones sobre sí mismo
del algoritmo utilizado, en este caso 3, es decir:
sha512(sha512(sha512(‘password’);
En la tercer línea de código se asigna a la variable $encPassword la

encriptación resultante (conocida también como hash) de la contraseña provista
por el usuario mezclada con el salt mediante las técnicas provistas al objeto
$encriptar.
Por último se coloca en el objeto usuario (entidad usuario) la contraseña ya

encriptada, para que pueda almacenarse en la Base de Datos.
Protección Utilizada: Symfony, Lógica de Programación.

P á g i n a | 79
4.6 Autenticación y Autorización
La autenticación es un proceso en el cual se verifica la identidad del

usuario, y la autorización es el rol que define los permisos que tiene para
utilizar ciertos elementos del sistema. Normalmente involucra un nombre de
usuario o correo electrónico y una contraseña.
El acceso que tendrá cada usuario a determinadas funciones del sistema

serán definidas en la aplicación misma o con ayuda de un framework asignando,
por ejemplo, mediante un campo en la base de datos a qué tipo de usuario
pertenece y cuáles son sus privilegios y/o excepciones al ejecutar determinadas
acciones dentro de la aplicación.
Un usuario puede generar un ataque intentando registrarse mediante un

gran número de pruebas. Para esto se puede limitar el número de intentos que se
le permite al usuario tratar de adivinar una combinación correcta. Otra opción por
la que puede optarse es la de colocar un intervalo de tiempo entre cada intento.
Control de Acceso
Symfony cuenta con un sistema de seguridad que se basa en identificar

primero al usuario (autenticación) y comprobando después si ese usuario
tiene acceso al recurso solicitado (autorización).
P á g i n a | 80
Cuando el usuario hace una petición el sistema determina si el usuario

necesita estar autenticado, y si lo necesita, envía una solicitud al usuario para
iniciar el proceso de autenticación. Esto no significa que el navegador mostrará el
formulario de inicio de sesión en todas las URL. Por ejemplo la aplicación ‘acerca
de’ será accesible por todos los usuarios sin necesidad de autenticación
haciéndolo como usuarios anónimos.
Si un usuario que ya ha iniciado sesión solicita ingresar a cierta

funcionalidad del sistema que requiera ciertos privilegios presentes un rol de
administrador y este usuario no cuenta con ese rol el sistema negará la entrada a
esta funcionalidad.
Las opciones de autenticación y control de acceso pueden ser modificados

en la sección access_control (normalmente mediante un archivo en YAML) de
acuerdo a los requerimientos de la Aplicación Web.
1 # app/config/security.yml
2 security:
3 # ...
4 access_control:
5 { path: ^/admin, roles: ROLE_USER_IP, ip: 127.0.0.1 }
6 { path: ^/admin, roles: ROLE_USER_HOST, host: symfony.com }
7 { path: ^/admin, roles: ROLE_USER_METHOD, methods: [POST,
PUT] }
8 - { path: ^/admin, roles: ROLE_USER }
Figura 4.13 Ejemplo de configuración del archivo YAML access_control para asignar permisos de
acceso.
P á g i n a | 81
La configuración del archivo access_control permite incluso restringir el

acceso a determinadas funcionalidades de acuerdo a su dirección IP o el host,
incluso filtrar los tipos de métodos aceptados.
Protección Utilizada: Symfony, Lógica de Programación.
4.7 Espionaje (Sniffing)
Cuando un atacante que tiene los medios para analizar el tráfico de

red, puede tener acceso a los datos enviados entre el usuario y el servidor
incluso a credenciales de acceso se le denomina sniffer.
Un analizador de paquetes es una utilidad que se ha utilizado desde la

versión original de Ethernet. Permite la detección de paquetes para capturar datos
a medida que se transmite a través de una red. Estos programas rastreadores de
paquetes son comúnmente utilizados por los profesionales de la red para ayudar a
diagnosticar problemas de red y también son utilizados por usuarios maliciosos
para capturar los datos no cifrados, como contraseñas y nombres de usuario en el
tráfico de red. Una vez que esta información es capturada, el usuario puede
obtener acceso al sistema o red.
P á g i n a | 82
Protección contra Espionaje
La Capa de Conexión Segura o SSL (del Inglés Secure Sockets Layer)

puede prevenir este tipo de problemas protegiendo el contenido de los datos
enviados y recibido mediante HTTP, además de que brinda confianza al usuario al
indicar que sus datos serán enviados de manera segura cuando en el navegador
visualizan el protocolo https. Garantiza la identidad del servidor y envíos de
datos protegidos mediante el uso de criptografía. Proporcionando al cliente la
confianza necesaria para que pueda registrarse de manera segura.
En esta tesis no se utilizará el SSL debido a que es necesario realizar un

registro ante alguna empresa que se encuentre autorizada para emitir
certificaciones de éste tipo como Verisign, sin embargo las proyecciones a futuro
implican la necesidad de utilizar certificados SSL y es por eso que son
contempladas.
Protección Utilizada: Encriptación de datos sensibles y cookies.
4.8 Desbordamiento
Un ataque de desbordamiento se realiza mediante la introducción

deliberada de más datos los que la Aplicación Web fue diseñada para
soportar. Los ataques por desbordamiento vulneran la falta de control de límite en
el tamaño de entrada que está siendo almacenado en memoria intermedia,
entonces los datos adicionales invaden la memoria reservada, y sobrescriben otra
región de la memoria destinada a sostener algunas de las instrucciones del
programa.
P á g i n a | 83
El efecto es una cascada, y eventualmente puede detener la aplicación del

sistema en el que se está ejecutando. Incluso los nuevos valores introducidos
pueden ser nuevas instrucciones, que podrían dar el atacante el control del equipo
(servidor).
Un ejemplo de este tipo de ataques es un Ataque de denegación de

servicios, también llamado ataque DoS (de las siglas en inglés Denial of Service),
que causa que un servicio o recurso sea inaccesible a los usuarios legítimos.
Actualmente los Navegadores Web ofrecen cierto grado de protección

contra ataques DoS “Los navegadores Web limitan el número de conexiones
simultáneas que harán a un origen… pero eso no significa que los errores de
ejecución que permiten a los ataques de denegación de servicio aparecerá en los
navegadores.” 6
Protección contra Desbordamiento
Existen diversas formas de protegerse contra ataques de sobrecarga,

algunas más especializadas que otras, por ejemplo un grado de protección podría
ser implementado mediante el uso de herramientas como CAPTCHA, que obligan
al usuario a introducir un código para cerciorarse de que es un usuario legítimo y
no un algoritmo o robot que está realizando múltiples peticiones y de esa forma
evitar que siga mandando solicitudes que sobrecarguen el sistema, claro esta es
una solución muy simple que no ofrece una protección total ante este tipo de
ataques.
__________________________________________________________________
6 Shema M. (2012). Hacking Web Apps: Detecting and Preventing Web Application Security
Problems [Hacking de Aplicaciones Web: Detección y Prevención de Problemas de
Seguridad de las Aplicaciones Web]. Estados Unidos de América: Syngress. p13.
P á g i n a | 84
Otro tipo de protección más completa es el uso de anti-DDoS, normalmente

ofrecidas por los proveedores de Internet, se trata de soluciones complejas y con
un costo extra, cuentan con sistemas de detección, mecanismos de
redireccionamiento y sistemas de mitigación.
Las proyecciones a futuro que tienen previstos para el sistema será

necesario contar con algún servicio de anti-DDoS.
4.9 Envenenamiento Cookies
Cuando el atacante utiliza "cookies envenenadas”, suele tratarse de un

cliente registrado que está familiarizado con la aplicación en cuestión. El atacante
puede alterar una cookie almacenada en su ordenador y enviarla de vuelta al
sitio Web.
Dado que la aplicación no espera cambios en la cookie, muchos de los

efectos son por lo general el cambio de campos de datos fijos, tales como cambios
en los precios en un sitio de comercio electrónico, cambio de identidad, incluso
cambios sobre privilegios que pudieran almacenarse en la cookie permitiendo al
atacante entrar a funciones del sistema en los cuales no tiene permitido el acceso.
El atacante puede aprovechar las técnicas de cifrado pobres o inexistentes por
parte de los desarrolladores Web para hacer cambios en la cookies.
P á g i n a | 85
Protección contra envenenamiento de Cookies
Al momento que un usuario inicia sesión normalmente es necesario crear

una cookie que permita una sincronización del equipo utilizado con la sesión
iniciada en el servidor. En algunos casos la cookie puede contener información del
cliente, como un Id y otros datos que sirvan para realizar un emparejamiento con
la información alojada en el servidor, esta información puede ser considerada
como sensible, por lo cual debe ser encriptada.
La encriptación de los datos contenidos en la cookie se sesión pueden

realizarse por las funciones que ofrece PHP. El framework Symfony encripta de
manera automática la cookie de sesión, utilizando las mismas técnicas descritas
en la encriptación de datos sensibles.
Protección Utilizada: Symfony.

CAPÍTULO V
PROTECCIÓN DE DATOS
P á g i n a | 87
5.1 Introducción
En México las personas físicas y morales que recaban datos personales son
sujetos que están regulados por la Ley Federal de Protección de Datos Personales en
Posesión de los Particulares. Dicha legislación establece la forma y las condiciones en
que deben ser usados los datos personales que se recaban al desarrollar cualquier
actividad económica en el ámbito privado.
El propósito de la Ley es garantizar la protección de la información que las

personas proporcionan al momento de adquirir un bien o contratar un servicio. Cada
persona en lo individual es la dueña de sus datos, y es la única que puede decidir
el uso que se les dará. Una de las primeras obligaciones establecidas por esta Ley es
que todos los sujetos regulados, es decir, quienes tengan bases de datos personales,
deben contar con un aviso de privacidad.
La protección jurídica del derecho a la privacidad en general y de la privacidad

de los datos, en particular es muy variable en todo el mundo, aunque suelen tener
objetivos en común, como por ejemplo todos aquellos países que pertenecen a la
Asamblea General de Naciones Unidas deben contemplar el Artículo 12 de la
"Declaración Universal de los Derechos Humanos" que dice:
"Nadie será objeto de injerencias arbitrarias en su vida privada, su familia, su

domicilio o su correspondencia, ni de ataques a su honra o a su reputación. Toda
persona tiene derecho a la protección de la ley contra tales injerencias o ataques." 1
______________________________________________________________________
1 Declaración Universal de Los Derechos Humanos. (s.f.). Recuperado el 11 de junio de 2013 de
http://www.un.org/es/documents/udhr/index_print.shtml.
P á g i n a | 88
El sistema a desarrollar manejará información personal de los clientes, por lo

cual es necesario contar con un aviso de privacidad de datos y seguir los
postulados de la Ley Federal de Protección de Datos Personales en
Posesión de los Particulares.
5.2 Datos personales
Los datos personales es información que puede usarse para identificar,

contactar o localizar a una persona en concreto como por ejemplo nombre, apellido,
dirección, correo electrónico, estado civil, CURP, lugar y fecha de nacimiento, domicilio,
número telefónico, grado de estudios, sueldo, datos biométricos como huellas, registro
de iris etc. por mencionar algunos, todo eso da una entidad a una persona e informa a
detalle sobre el individuo. Por lo tanto no es la cantidad de información que se nos
proporciona sino la importancia que tiene estos datos al interactuar con personas y
organizaciones.
“Datos personales: Cualquier información concerniente a una persona física

identificada o identificable.” 2.
Por lo tanto corroboramos que los datos no solo es información sino una entidad
para cada una de las personas.
_____________________________________________________________________
2 Estados Unidos Mexicanos. Congreso General. Ley Federal de Protección de Datos Personales en
Posesión de los Particulares. DOF 05-07-2010. Diario Oficial de la Federación. 05 de julio de
2010. p. 5
P á g i n a | 89
Dentro de los datos personales hay una categoría que se denomina “datos
personales sensibles”, que como se mencionó en el Capítulo IV (Seguridad en
Aplicaciones Web) requieren especial protección como contraseñas y números de
cuentas bancarias. También los datos sensibles pueden tratarse de información que
puede revelar aspectos íntimos de una persona o dar lugar a discriminación, como el
estado de salud, información genética, creencias religiosas, filosóficas y morales,
afiliación sindical, opiniones políticas, origen racial o étnico y preferencia sexual, por
mencionar algunos.
5.3 Protección de Datos
La protección de datos es una disciplina jurídica relativamente nueva, cuyo

objetivo se centra en proteger la intimidad de las personas frente al uso y
posesión de información personal de manera indiscriminada en manos de
terceros y que pueda representar un riesgo para la persona que comparte su
información. En muchos países, incluyendo México, es un derecho legal que sus
ciudadanos tienen al brindar información personal con cualquier institución,
organización y cualquier dependencia que los solicite. La automatización de
información y el rápido crecimiento de las TICs implementadas en casi cualquier
actividad, hizo necesaria la creación de un marco jurídico que proteja los datos
recopilados, almacenados, de organización y así mismo de acceso para evitar
cualquier abuso hacia la persona.
P á g i n a | 90
La seguridad y privacidad (temas de los cuales trata la protección de datos) en

sistemas informáticos es un aspecto importante. En un estudio realizado por la
empresa Barracuda Networks, las personas fueron encuestadas sobre las
características que buscaban en las redes sociales y se concluyó que existen 4
aspectos fundamentales que influyen al usuario al momento de elegir alguna red
social para registrarse y usarla, y que a continuación se ilustra.
Figura 5.1 Balanza representativa de los aspectos que influyen el uso de las redes sociales.
Esa misma balanza puede ser utilizada para representar los aspectos que
influyen en el uso en general de los sistemas orientados a tecnologías web y que tratan
con datos personales de sus usuarios.
Para ofrecer protección a los usuarios se toman en cuenta medidas tácticas y

tecnológicas así como apego a las legislaciones y respeto a los derechos de los
usuarios, esto aumenta la confianza sobre el sistema e influye directamente en el
éxito del mismo.
P á g i n a | 91
La protección de datos abarca dos aspectos generales que se pueden identificar

en la mayoría de las legislaciones correspondientes a cada país:
 Protección de datos desde el aspecto de posesión y tratamiento: Se enfoca

en uso que le dará la organización que posea los datos personales, las
limitaciones que posee sobre ellos, los derechos que posee el usuario que
brinda la información, así como los acuerdos entre ambas partes.
 Protección de datos desde el aspecto técnico: Son medidas de seguridad
implementadas mediante las tecnologías utilizadas para el almacenamiento y
tratamiento de información, en los sistemas de TI, por ejemplo, puede referirse a
la infraestructura de seguridad, firewalls, frameworks, protocolos de seguridad
(como https), técnicas de encriptación de datos sensibles, etc.
Si bien la “protección de datos” está más enfocada a términos como “privacidad”

o “confidencialidad” parte de dicha protección implica la implementación de
medidas de seguridad que eviten el daño, pérdida, alteración, destrucción o el
uso, acceso o tratamiento no autorizado de la información personal manejada. Es
ahí donde la protección de datos es vista desde el aspecto técnico, y las medidas de
seguridad necesarias se han descrito en el Capítulo IV (Seguridad en Aplicaciones
Web). Por ejemplo en la Ley Federal de Protección de Datos Personales aplicada en
México contempla lo siguiente:
“Artículo 19.- Todo responsable que lleve a cabo tratamiento de datos

personales deberá establecer y mantener medidas de seguridad administrativas,
técnicas y físicas que permitan proteger los datos personales contra daño, pérdida,
alteración, destrucción o el uso, acceso o tratamiento no autorizado.” 3
_____________________________________________________________________
2010. p. 59
P á g i n a | 92
Los aspectos relacionados con la protección de datos es importante en el

desarrollo de este sistema puesto que no sólo se manejará información
personal de los clientes, sino también los datos de los flujos de compras y
ventas de sus negocios, y es importante hacerle notar al usuario de qué
manera serán tratados dichos datos.
5.4 Instituto Federal de Acceso a la Información y Protección de

Datos
En México se ha creado una institución que protege la información de las

personas, el IFAI (Instituto Federal de Acceso a la Información y Protección de datos)
es un organismo del Poder Ejecutivo de México, que tiene autonomía presupuestaria y
decisión propia y fue creado a raíz de una iniciativa de ley presentada durante el
Gobierno de Vicente Fox.
Figura 5.2 Logotipo del Instituto Federal de Acceso a la Información

y Protección de Datos de 2013
P á g i n a | 93
La misión del IFAI es:
“Trabajar para garantizar el derecho de los ciudadanos a la información pública

gubernamental y a la privacidad de sus datos personales, así como para promover en
la sociedad y en el gobierno la cultura del acceso a la información, la rendición de
cuentas y el derecho a la privacidad". 4
Su marco jurídico abarca 2 leyes principales:
1. Ley Federal de Transparencia y Acceso a la Información Pública

Gubernamental (publicada en el Diario Oficial de la Federación el 11 de
junio de 2002): La cual tiene por objetivo reconocer y regular el derecho
individual al acceso a la información de las instituciones y organismos del
Estado.
2. Ley Federal de Protección de Datos Personales (publicada en el Diario

Oficial de la Federación el 5 de julio del 2010): Cuyos objetivos se centran en
regular la forma en que las personas físicas o morales llevan a cabo el
tratamiento de datos personales en el ejercicio de sus actividades.
Además la Constitución Política de los Estados Unidos Mexicanos, en su

artículo 16, reconoce el derecho a la protección de datos personales como una
garantía individual, al señalar que toda persona tiene derecho a la protección de sus
datos personales, al acceso, rectificación y cancelación de los mismos, así como a
manifestar su oposición en los términos que fije la ley
____________________________________________________________________
4 Instituto Federal de Acceso a la información y Protección de Datos Misión Visión y Objetivos. (s.f.).
Recuperado el 10 de Junio de 2013 de
http://inicio.ifai.org.mx/_catalogs/masterpage/misionViosionObjetivos.aspx.
P á g i n a | 94
A Partir del 12 de Junio del 2003 cuando entró en vigor la ley federal de
transparencia y acceso a la información pública, entidades de gobierno y el sector
privado está obligado a atender solicitudes de información bajo vigilancia del IFAI. Esta
dependencia está encargada:
 Difundir el conocimiento de protección de datos a la sociedad mexicana.

 Proteger la información proporcionada por los titulares en las diferentes
dependencias ya sean privadas o de gobierno.
 “… promover su ejercicio y vigilar por la debida observancia de las
disposiciones previstas en la presente Ley y que deriven de la misma; en
particular aquellas relacionadas con el cumplimiento de obligaciones por parte
de los sujetos regulados por este ordenamiento.” 5
 Resolver aquellos problemas que impidan el acceso a la información a la
sociedad de las diferentes dependencias.
5.5 Ley Federal de Protección de Datos Personales en

Posesión de Particulares
La Ley Federal de Protección de Datos en Posesión de Particulares (LFPDPPP)

consta de 69 artículos, 11 capítulos y apartados transitorios que expresan el
reglamento a la protección de datos personales en posesión de los particulares.
______________________________________________________________________
2010.p. 12
P á g i n a | 95
Los 11 capítulos con los cuales cuenta la Ley y que resumen a grandes rasgos
cuál es su finalidad son los siguientes:
1. Capítulo I Disposiciones Generales

2. Capitulo II Los Principios de Protección de Datos Personales.
3. Capítulo III De los Derechos de los Titulares de Datos Personales
4. Capitulo IV Ejercicio de los Derechos de Acceso, Rectificación,
Cancelación y Oposición
5. Capítulo V De la Transferencia de Datos
6. Capítulo VI Las Autoridades
7. Capítulo VII Del Procedimiento de Protección de Derechos

8. Capítulo VIII Procedimiento de Verificación
9. Capítulo IX Procedimiento de Imposición de Sanciones
10. Capitulo X Infracciones y Sanciones
11. Capitulo XI Delitos en Materia del Tratamiento Indebido de Datos
Personales
Esta ley fue aprobada el día 5 de julio de 2010 en el sexenio del el ex

presidente Felipe de Jesús Calderón Hinojosa donde el Congreso de la Unión. Un día
después de esa fecha entró en vigor la publicación en el diario Oficial de la Federación
y todas las organizaciones personas físicas o morales que tengan manipulen
datos personales están obligados a acatar la normatividad y de ser lo contrario se
harán acreedores a las sanciones que la ley indique.
La LFPDPPP identifica a los dos principales actores y se refiere a ellos como

Titular y Responsable, siendo el titular el usuario que comparte su información y el
responsable es la organización o persona que solicita dicha información.
P á g i n a | 96
El responsable es aquel que realiza el tratamiento de los datos, entendiéndose

por tratamiento de acuerdo a la LFPDPPP lo siguiente:
“XVIII. Tratamiento: La obtención, uso, divulgación o almacenamiento de datos

personales, por cualquier medio. El uso abarca cualquier acción de acceso, manejo,
aprovechamiento, transferencia o disposición de datos personales.” 6
Se identifican 3 fases en las que el responsable adquiere ciertas obligaciones en

el tratamiento de los datos personales del titular:
5.5.1 Fase 1: Obtención y uso de datos
 Usar a los datos personales respetando la LFPDPPP, desde el momento de su

obtención.
 Obtener el consentimiento del titular o autorización para el tratamiento de sus
datos personales, salvo las excepciones previstas en el artículo 10 de la
LFPDPPP.
 Dar a conocer el aviso de privacidad para que el titular esté informado sobre
quién y para qué se recaban sus datos personales, cómo ejercer sus derechos
ARCO, así como los términos y condiciones generales del tratamiento a los que
será sometida su información.
 No utilizar medios engañosos o fraudulentos para obtener los datos personales.
 Recabar sólo aquellos datos personales que sean necesarios para la finalidad
que se obtienen.
_____________________________________________________________________
2010.p. 6
P á g i n a | 97
5.5.2 Fase 2: Tratamiento de los datos
 Sólo utilizar los datos personales para las finalidades que autorizó el titular o
consintió.
 Mantener los datos personales actualizados y correctos.
 Conservar los datos personales sólo por el periodo que sea necesario para llevar
a cabo la finalidad para la que se obtuvieron.
 Sólo compartir los datos personales con terceros si el titular lo autorizó, salvo las
excepciones previstas en el artículo 37 de la LFPDPPP..
 Guardar la confidencialidad de los datos personales.
 Implementar medidas de seguridad que eviten el daño, pérdida, alteración,
destrucción o el uso, acceso o tratamiento no autorizado de los datos
personales.
 Informar al titular si ha ocurrido una vulneración a la seguridad de las bases de
datos que pueda afectar sus derechos patrimoniales o morales, para que éste
pueda tomar las medidas necesarias para su protección.
5.5.3 Fase 3: Conclusión del uso de los datos personales
 Eliminar de las bases de datos o archivos los datos personales del titular,
cuando hayan concluido las finalidades que dieron origen a su obtención.
Es importante hacerle notar al titular que sus datos personales no siempre se

podrán eliminar de manera inmediata, pues a veces será necesario conservarlos por
algún periodo por cuestiones legales, de responsabilidades, o contractuales. A este
periodo la Ley le denomina bloqueo, y durante el mismo los datos personales no
P á g i n a | 98
podrán ser utilizados para ninguna finalidad, y una vez concluido deberán ser
eliminados.
5.6 Aviso de Privacidad
El aviso de privacidad es un documento físico, electrónico o en cualquier otro

formato, en el que el responsable deberá dejar claramente establecido el tipo de
información personal que requerirá, así como el uso que dará a esa información.
“Artículo 15.- El responsable tendrá la obligación de informar a los titulares de los

datos, la información que se recaba de ellos y con qué fines, a través del aviso de
privacidad.” 7
El tratamiento de los datos deberá limitarse y ser acorde con el fin para el cual
son recabados por el responsable, y contar con el consentimiento del titular o dueño de
los datos, que es cada persona en lo individual.
Si el responsable pretende usar los datos para un fin distinto, que no resulte
compatible con los fines establecidos en el aviso de privacidad, necesitará obtener
nuevamente el consentimiento del titular. El aviso de privacidad debe contener lo
siguiente:
 Los datos personales que serán recabados del titular.

 El propósito para el cual son recolectados y usados los datos.
______________________________________________________________________
2010. p. 8
P á g i n a | 99
 La identidad y domicilio de la empresa o lugar de trabajo del responsable.

 Las opciones y medios que el responsable ofrecerá a los titulares para limitar el
uso o divulgación de su información.
 Los medios para ejercer los derechos de acceso a los datos, rectificación,
cancelación u oposición de los mismos, de conformidad con lo dispuesto por la
LFPDPPP.
 Si es necesario, las transferencias de datos que realizará el responsable y su
finalidad. Consultando previamente al titular y contando con la aceptación de
transferencia de sus datos a terceros. Salvo aquellas excepciones marcadas en
la LFPDPPP en su artículo 37.
 El procedimiento y medio por el cual el responsable informará a los titulares de

los datos sobre posibles cambios en el aviso de privacidad.
 En el caso de que el responsable maneje datos personales sensibles, el aviso
de privacidad deberá señalar expresamente que se trata de este tipo de datos.
 En el aviso de privacidad el responsable deberá precisar el procedimiento a
seguir en caso de que el titular de los datos cambie de opinión posteriormente y
decida revocar su consentimiento
Cuando los datos personales se obtengan personalmente del titular, el

responsable debe poner a disposición de sus clientes el aviso de privacidad en el
momento en que recaba la información de forma clara y fehaciente, salvo que el
aviso se halla hecho llegar con anterioridad.
Cuando los datos personales sean obtenidos directamente del titular por cualquier
medio electrónico, óptico, sonoro, visual o a través de cualquier otra tecnología, el
responsable deberá proporcionarle al titular de manera inmediata por lo menos la
P á g i n a | 100
información sobre la identidad y domicilio de tu empresa y el propósito para el

cual recolectas y usarás los datos. También el responsable deberá proveer los
mecanismos para que el titular conozca el texto completo del aviso de privacidad.
Figura 5.3 Imagen que ilustra algunos aspectos que abarca el

aviso de privacidad y quienes lo requieren
P á g i n a | 101
Si el responsable no pone a disposición de los clientes el aviso de privacidad estará

cometiendo una infracción a la ley, por lo cual podría aplicar una multa de 100 a
160,000 días de salario mínimo vigente en el Distrito Federal. Lo mismo aplica si falta
alguno o todos los elementos de información que debe contener el aviso de privacidad.
Otra posible infracción relacionada la constituye la transferencia de datos a terceros,

sin notificar a estos las limitaciones establecidas por los titulares de los datos. En este
caso la multa podría ser de 200 a 320,00 días de salario mínimo vigente en el Distrito
Federal.
Además de acuerdo con el Articulo 64 de la LFPDPPP: “En caso de que de manera

reiterada persistan las infracciones… tratándose de infracciones cometidas en el
tratamiento de datos sensibles, las sanciones podrán incrementarse hasta por dos
veces, los montos establecidos.” 8
El sistema desarrollado en esta tesis sólo está contemplado hasta la

aplicación Web con una API cerrada, por lo cual su aviso de privacidad
únicamente contemplará los aspectos relacionados con el uso de los datos
personales tratados en la aplicación Web, sin embargo a futuro no se
descarta la posibilidad de la creación de aplicaciones para móviles y por lo
cual deban ser contempladas en el aviso de privacidad para aquel entonces.
______________________________________________________________________
2010. p. 8
P á g i n a | 102
5.7 Derechos ARCO
Los derechos ARCO son aquellos que la LFPDPPP otorga a los titulares de los
datos personales el derecho a acceder, rectificar y cancelar su información personal en
posesión de terceros, así como oponerse a su uso.
5.7.1 Acceso
Cada uno de los titulares de los datos personales tienen derecho de acceder a
su información personal que esté en posesión del responsable, a fin de conocer
cuál es y el estado en que se encuentra, es decir, si es correcta y actualizada y saber
para conocer para qué fines se utiliza.
A través del ejercicio del derecho de acceso, el titular puede conocer las
características generales del uso al que están sometidos los datos personales.
Entre la información a la que se puede acceder se encuentra la siguiente:
 Sus datos personales utilizados.

 La finalidad del tratamiento de sus datos personales.
 Los nombres de las organizaciones con quienes se comparten sus datos
y sus fines.
 La fuente de la cual fueron obtenida su información personal.
P á g i n a | 103
5.7.2 Rectificación
Todos los titulares de los datos personales tienen derecho a rectificar su

información personal, cuando ésta resulte ser incompleta o inexacta. En otras
palabras, pueden solicitar a quien utilice sus datos personales que los corrija en caso
de que resulten ser incorrectos o se encuentren desactualizados.
“Artículo 24.- El titular de los datos tendrá derecho a rectificarlos cuando sean
inexactos o incompletos.” 9
5.7.3 Cancelación:
Los titulares de los datos personales pueden solicitar la cancelación, es decir,

que se eliminen tus datos personales cuando consideren que no están siendo utilizados
o tratados conforme a las obligaciones y deberes que tiene el responsable y que se
encuentran contenidos tanto en la LFPDPPP como en su Reglamento.
Existen ciertas excepciones por las cuales los datos personales no podrán ser
eliminados, estas excepciones se aplicarán cuando:
 Se refiera a las partes de un contrato privado, social o administrativo y sean

necesarios para su desarrollo y cumplimiento.
______________________________________________________________________
2010. p. 9
P á g i n a | 104
 Deban ser tratados por disposición legal.

 Se obstaculicen actuaciones judiciales o administrativas vinculadas a
obligaciones fiscales, la investigación y persecución de delitos o la actualización
de sanciones administrativas.
 Sean necesarios para proteger los intereses jurídicamente tutelados del titular.
 Sean necesarios para realizar una acción en función del interés público.
 Sean necesarios para cumplir con una obligación legalmente adquirida por el
titular.
 Sean objeto de tratamiento para la prevención o para el diagnóstico médico o la
gestión de servicios de salud, siempre que dicho tratamiento se realice por un
profesional de la salud sujeto a un deber de secreto.
5.7.4 Oposición
Los titulares de los datos personales tienen derecho a oponerse al uso de su

información personal o exigir el cese del mismo cuando:
 Por alguna causa legítima sea necesario parar el uso de los datos personales, a
fin de evitar un daño a su persona.
 No quieran que su información personal sea utilizada para ciertos fines o por
ciertas personas, empresas, negocios, asociaciones, o cualquier tercero.
P á g i n a | 105
El incumplimiento de los derechos de los titulares como ya se ha mencionado

puede ser causa de infracciones monetarias, e incluso puede llegar a ser considerado
como delito con sanciones de hasta 5 años de prisión.
“Artículo 68.- Se sancionará con prisión de seis meses a cinco años al que, con
el fin de alcanzar un lucro indebido, trate datos personales mediante el engaño,
aprovechándose del error en que se encuentre el titular o la persona autorizada para
transmitirlos.” 10
El aviso de privacidad creado para el sistema desarrollado puede

consultarse en el Anexo B Aviso de Privacidad
______________________________________________________________________
2010. p. 19
CAPÍTULO VI
MODELOS DE DISTRIBUCIÓN DE SOFTWARE
P á g i n a | 107
6.1 Preámbulo
Desde los inicios del software en los años 50’s, se han buscado distintas
formas de distribuirse, pero en sus inicios el software no era considerado un
producto, sino un añadido que los fabricantes de las computadoras incluían en sus
equipos.
No fue hasta mediados de los 60’s cuando el software comenzó a ser

considerado como un producto y sugirieron nuevas formas de distribución, la
mayoría de ellas impulsadas por un objetivo comercial, aunque también han
surgido muchas otras formas de distribución que tienen objetivos distintos al de
lucrar directamente con el software.
A finales de los 60’s IBM ofrecía tiempo compartido de sus mainframes que
incluían el poder de cómputo y almacenamiento de bases de datos, a manera de
renta. Pero el modelo de renta de mainframes no lo logró perdurar debido a la
escasa infraestructura para el control remoto de aquel tiempo y las pocas opciones
de seguridad existentes.
Las compañías empezaron a distribuir de manera independiente sus

productos y esto llevo a poner restricciones al software que producían, de esta
forma, surgieron las "licencias de software", que establecían un contrato entre los
usuarios y la compañía creadora del software para que este no fuera modificado,
copiado y distribuido de manera distinta a lo estipulado en dicho contrato, entre
otras restricciones que protegían sus productos.
P á g i n a | 108
En la década de los 80´s, el avance tecnológico permitió crear las

computadoras personales llevando así la tecnología a cientos de hogares (ya no
sólo grandes empresas) aumentando enormemente el mercado para los
desarrolladores de software.
Con el crecimiento de la Web a finales de los años 90’s comenzó a renacer

la idea de distribución del software bajo una renta, ahora conocido como Software
como Servicio, éste modelo, como ya se mencionó, se remonta a los años 60’s y
posteriormente abandonada, pero cuando salesforce.com fue fundada en 1999 se
convirtió en pieza fundamental para retomar dicho modelo, principalmente por la
creación de su CRM funcionando bajo esta distribución.
6.1.1 Web 2.0
La Web 2.0 surgió en 1999, este modelo de web permitió tener páginas
dinámicas que se generaban al momento de la visualización. Estas páginas
dinámicas se creaban al momento en que se pedían al servidor y dio un enfoque
más amplio a los programadores, sobre lo que podían ser los sistemas
informáticos. Mediante la Web 2.0 el contenido de las páginas podía generarse de
acuerdo a las acciones del usuario y esto permitió una navegación más amigable.
La Web 2.0 se puede definir como un conjunto de principios y prácticas

que se aplican al desarrollar una plataforma web.
P á g i n a | 109
En la primera conferencia de la Web 2.0, en octubre del 2004, Tim O'Reilly

fundador de O’Reilly Media Inc y John Battelle, definieron un principio que tenían
que tener la web 2.0: “que la Web debe de verse como una plataforma”.
Aunque el término sugiere una nueva versión de la World Wide Web, no se

refiere a una actualización de las especificaciones técnicas de la web, sino
más bien a cambios en la forma en la que desarrolladores de software y
usuarios finales utilizan la Web. Los usuarios pueden proporcionar los datos que
se encuentran en un sitio de la Web 2.0 y ejercer cierto control ellos.
“La Web 2.0 es la red como plataforma que abarca todos los dispositivos
conectados a ella, las aplicaciones Web 2.0 son las que representan la mayoría de
las ventajas intrínsecas de esta plataforma: la entrega de software como un
servicio continuamente actualizado que mejora mientras más personas lo utilizan,
consumiendo y remezclando datos de múltiples fuentes, incluyendo usuarios
individuales, mientras que la prestación de sus propios servicios de datos permite
ser remezclada por otros, creando el efecto a través red de una ‘arquitectura de
participación’, y que van más allá de la metáfora de la Web 1.0 para ofrecer
mejores experiencias de usuario .” 1
Algunas características principales de la Web 2.0 son:
 La Web 2.0 ve a los usuarios como contribuyentes de la misma.

 Los usuarios indexan contenido mediante herramientas sociales de
acuerdo a sus propios criterios creando una folksonomía.
_________________________________________________________________
1 Web 2.0: Compact Definition? [La Web 2.0 ¿En una definición compacta?]. (01 de octubre de
2005). Recuperado el 21 de junio de 2013 de http://radar.oreilly.com/2005/10/web-20-
compact-definition.html.
P á g i n a | 110
 Ofrece una experiencia enriquecida a los usuarios mediante

tecnologías que mejorar la interacción del usuario con las
aplicaciones web.
 Promueve la apertura, la libertad y la inteligencia colectiva.
“La web La Web 2.0 es la representación de la evolución de las

aplicaciones tradicionales hacia aplicaciones web enfocadas al usuario final. El
Web 2.0 es una actitud y no precisamente una tecnología.” 2 La Web 2.0 sugiere
que las aplicaciones de software se deben de ver como servicios y no como
paquetes de software, ya que no se puede comprar una plataforma web para cada
aplicación.
El concepto de la Web 2.0 es una pieza fundamental para el advenimiento

las nuevos de los modelos de negocios entorno al software, la distribución
del software como servicio se retoma al momento de que la Web 2.0 es
‘concebida’, es decir la Web 2.0 nace junto con esta nueva modalidad de
ofrecer el acceso a las aplicaciones que son procesadas remotamente.
6.1.2 Cloud Computing
El cloud computing es un modelo de servicio del software que permite

acceso cómodo a un servicio a través de internet. Este servicio consiste en
brindar todas las prestaciones que tiene tener una computadora, como por
ejemplo redes, servidores, almacenamiento, aplicaciones y servicios, que se
pueden proveer al cliente rápidamente y sin esfuerzo de gestión por parte del
administrador, o la interacción de proveedor de servicios.
_________________________________________________________________
2 Caivano R., Villoria. (2009). Aplicaciones Web 2.0 para aplicaciones educativas en la U.N.V.M.
Cordoba, República Argentina: Eduvim. p. 11
P á g i n a | 111
Este modelo de computación en la nube promueve la disponibilidad y se

compone de características tanto de modelos de servicio como de despliegue.
Las características básicas de un servicio de computación en la nube, se

componen de:
 “Servicio bajo demanda”, esta parte del modelo determina lo que se

va a utilizar, como se va a utilizar y cuando se va a utilizar, para
reducir al mínimo el uso del equipo, reduciendo los costes a la par.
 “Amplio acceso a la red” Los accesos a los servicios de computación
en la nube están dados a través de internet, por lo que tener un
amplio acceso a la red es indiscutiblemente necesario en los
sistemas. Los accesos a la red están dados por políticas de la
empresa, y por normas generales de las conexiones de redes, los
cuales permiten un servicio continuo.
 “Cola de recursos informáticos” esto consiste en juntar recursos de
los proveedores para ofrecerlos a diferentes clientes utilizando el
modelo “multi-inquilinos”, que consiste en tener en el sistema
múltiples recursos físicos y virtuales, funcionando de forma dinámica.
 “Elasticidad” las capacidades de un proceso pueden verse ocupadas
de una forma rápida
Los proveedores de cloud computing ofrecen sus servicios de acuerdo con

varios modelos fundamentales:
 Infraestructura como Servicio o IaaS (del inglés Infrastructure as

a Service): Los proveedores de IaaS ofrecen medios de
almacenamiento básico y capacidades de cómputo mediante
maquinas virtuales.
 Plataforma como Servicio o PaaS (del inglés Platform as a
Service): Sus servicios se relacionan con los ambientes de
P á g i n a | 112
desarrollo y empaquetamiento de módulos o complementos

comúnmente utilizando APIs preconfiguradas o Frameworks, sus
servicios son utilizados para crear nuevos sistemas y pueden abarcar
todas las fases del ciclo de desarrollo y pruebas de software.
 Software como servicio o SaaS (del inglés Software as a
Service): Provee a los usuarios una aplicación completa bajo
demanda, alojada en la infraestructura del proveedor SaaS y que
sirve a múltiples organizaciones o clientes.
Figura 6.1 Modelos del Cómputo en la Nube
La imagen anterior muestra los distintos tipos de modelos que abarca el

cómputo en la nube y los ‘módulos’ que pueden ser controlados por el cliente en
un color más oscuro, mientras los ‘módulos’ de color más claro son controlados
por el proveedor del servicio.
P á g i n a | 113
Figura 6.2 Representación de las acciones básicas del lado del cliente (Cloud Client)
El cloud computing sirve como preámbulo ya que es el modelo general al cual

pertenece la forma de distribución elegida para el sistema desarrollado en
esta tesis, el Software como Servicio el cual será visto más adelante.
P á g i n a | 114
6.4 Modelos de Distribución de Software
Para este capítulo debe entenderse como modelo de distribución, la forma

en que será llevado el producto (aplicación) hasta sus clientes o usuarios y
los términos acordados entre ambos para el uso de dicho software.
Basado en lo anterior, pueden distinguirse dos formas generales de

distribución del software, de acuerdo con en el sitio en el que reside en su
totalidad o gran parte de la lógica de negocios y el tipo de contrato que se llevará
entre ellos:
 Software Local (On-premises Software)

 Software como Servicio (Software as a Service)
Estos modos de distribución están contemplados sólo para software de

aplicación. El software de desarrollo también puede ser local y utilizando el
cómputo en la nube normalmente se distribuye como Plataforma como Servicio.
De igual forma los Sistemas Operativos también pueden ser locales y mediante
cloud computing comúnmente son distribuidos como Infraestructura como
Servicio.
P á g i n a | 115
6.5 Software Local
El software Local o Software on-promises, son aplicaciones de escritorio,

lo que quiere decir que necesitan una instalación en el equipo del cliente,
cuando se trata de software comercial, este modelo tradicional implica costos de
adquisición iniciales importantes y requieren un mantenimiento periódico, soporte
y actualizaciones costosas que se multiplican en la adquisición inicial.
Hablando de software comercial normalmente este también es conocido

como software propietario, como software de código cerrado o como software no
libre, utiliza licencias de tipo CLUF (Contrato de Licencia para Usuario Final) o
EULA (del inglés End User License Agreement). En ellas los propietarios
establecen los derechos de uso, distribución, redistribución, copia, modificación,
cesión y en general cualquier otra consideración que se estime necesaria.
No todo el software on-promises tiene licencias tan restrictivas, existen

licencias basadas en filosofías de distribución de software mucho más
flexibles como lo es el software libre, que suelen estar disponibles gratuitamente;
sin embargo no es obligatorio que sea así, por lo tanto no se debe asociar
software libre con "software gratuito" ya que, conservando su carácter de libre,
puede ser distribuido comercialmente.
El negocio detrás del software libre se caracteriza por la oferta de servicios

adicionales al software como: la personalización o instalación del mismo, soporte
técnico, donaciones, patrocinios o como un elemento de responsabilidad social
corporativa; en contraposición al modelo de negocio basado en licencias
predominante en el software de código cerrado.
P á g i n a | 116
También pueden encontrase modelos de licenciamiento que son de tipo

freeware (software gratuito) y donationware (software distribuido mediante
donaciones), que no necesariamente tienen que ser software libre.
“Tradicionalmente en el modelo de entrega del software on-promises, el

desarrollador de software proporciona el código objeto (ejecutable) en medios de
almacenamiento (por ejemplo, un DVD-ROM) con una licencia (usuario final). El
titular de la licencia instala y ejecuta el software en un sistema local (o red) y tiene
acceso a los datos de almacenamiento local (o en red).” 3
Como se observa el software on-promises se maneja a través de

licencias ya sea con ciertas restricciones o por completa libertad llegando incluso
a permitir al usuario modificar el código y distribuirlo de manera comercial. Existe
una gran variedad de licencias, especialmente abundan aquellas que están
basadas en conceptos similares al de software libre, algunas con más libertad que
otras o regidas por distintas filosofías. Pueden existir tantas licencias como
acuerdos concretos se den entre el autor y el licenciatario.
Independientemente del tipo de licencia manejada por el software local,

este tipo de distribución se encuentra con los problemas descritos en el capítulo
2 en tema que trata sobre las aplicaciones de escritorio, en las que los costos de
instalación y mantenimiento son elevados para los proveedores de software.
Además tratándose de software comercial, los costos de adquisición

resultan muy altos y las actualizaciones no siempre son gratuitas.
_________________________________________________________________
3 Kane R. (2009). Software Escrow for Dummies [´Fideicomiso´ de Software para Tontitos].
Estados Unidos de América: Iron Mountain Digital. p. 37
P á g i n a | 117
6.6 Software como Servicio
El software como servicio o SaaS (del inglés Software as a Service) a veces

también denominado como Software bajo demanda. Es un modelo de
distribución de software basado en un alojamiento en la ‘nube’, el cual es
accesible por sus usuarios normalmente mediante un Navegador Web.
“Entrega de Software basada en la nube se ejecuta en la infraestructura que

el proveedor de SaaS gestiona. Las aplicaciones SaaS se acceden a través de
Internet y por lo general pagan por suscripción.” 4
En el modelo de software como servicio, la aplicación o el servicio, se

despliega a partir de un centro de datos centralizado través de una red (Internet,
Intranet, Extranet) y facilita el acceso y uso de manera recurrente conforme a una
tarifa. A los usuarios se les "alquila", "suscribe", "se les asigna", o "se les otorga
acceso a" las aplicaciones de un proveedor central.
Los modelos de negocio varían de acuerdo con el nivel al que el software

se hace más eficiente, comenzando con el precio más bajo y aumentando al
adquirir funcionalidades con valor agregado a través de la personalización para
mejorar aún más los procesos de negocio digitalizados.
_________________________________________________________________
4 Software as a Service [Software como Servicio]. (s.f.). Recuperado el 20 de junio de 2013 de
http://cloudtaxonomy.opencrowd.com/taxonomy/software-as-a-service/.
P á g i n a | 118
A diferencia del software tradicional que convencionalmente se vende como

una licencia perpetúa con un costo inicial (y una cuota de apoyo continuo
opcional), los proveedores SaaS fijan sus precios generalmente utilizando una
tarifa de suscripción, comúnmente una cuota mensual o una cuota anual. El costo
de instalación inicial para SaaS es típicamente menor que el software de la
empresa equivalente.
“Las organizaciones pronto encuentran que mientras que el software

tradicional puede ser personalizado, que a menudo conduce al bloqueo y la
imposibilidad de mantener cambios a través de una actualización” 5
SaaS permite que la adquisición de nuevos usuarios o clientes sea

relativamente menos complicado, utilizando el modelo freemium para ofrecer
aplicaciones. Las cuotas de suscripción son cobradas sin tomar en cuenta las
tasas de uso. El éxito de un modelo de suscripción radica en la escalabilidad del
mismo. Los ingresos se pueden volver exponenciales mientras los costes crecen
marginalmente.
El Software como Servicio también puede manejarse con distintos tipos de

modelos contratos en los cuales se incluyen las cláusulas del proveedor con el
usuario, algunas de los modelos más comunes son:
 Basado en suscripción: Mediante un pago mensual que se calcula sobre

el software utilizado, incluye un compromiso en cuanto al número real de
usuarios.
_________________________________________________________________
5 A Brief History of SaaS [Una breve historia sobre el Software como Servicio]. (s.f.). Recuperado
el 20 de junio de 2013 de http://www.computerworld.com/pdfs/Service-Now-
BriefhistoryofSaaS.pdf.
P á g i n a | 119
 Basada en el uso: El pago se determina mediante el uso de aplicaciones y

por lo general se relaciona los niveles de uso. El pago puede estar
vinculado al número de equipos que ejecutan la aplicación. También puede
descrito para el número máximo de usuarios concurrentes.
 Basado en transacción: Se cobran a los clientes por cada transacción de
negocios.
 Basado en el valor: En la prestación de cualquier software que se necesita
para alcanzar los objetivos de negocio, el pago está vinculado a la
consecución de esos objetivos.
 Fixed-Fee Modelo: Una opción emergente, los usuarios generalmente
pagan una cuota mensual predeterminada basada en el número de
usuarios soportados, los módulos de aplicación se alquilan y los niveles de
servicio y soporte especificados por el cliente, en otras palabras, sería una
combinación de distintos modelos.
“Los ingresos de SaaS en América Latina se prevén en un total de $419,7

millones (dólares) en 2012, frente a los $ 331,1 millones del año pasado. En
América Latina, SaaS se ha hecho más popular para implementarse en las áreas
de dirección de correo electrónico, la gestión financiera (contabilidad),
automatización de fuerza de ventas, servicios al cliente y gestión de gastos. Si
bien la adopción regional será positiva, se tiene plena confianza de que Brasil y
México controlarán la mayoría de las oportunidades de adopción de este modelo y
sus ingresos. En los próximos dos años, los compradores serán más propensos a
comprar soluciones SaaS de CRMs y aplicaciones ERP.” 6
_________________________________________________________________
6 Gartner Says Worldwide Software-as-a-Service Revenue to Reach $14.5 Billion in 2012 [Gartner
dice que los ingresos del Software como Servicio a nivel mundial pueden llegar a $14,5 mil
millones en 2012]. (27 de marzo de 2012). Recuperado el 20 de junio de 2013 de
http://www.gartner.com/newsroom/id/1963815.
P á g i n a | 120
2011 2012 2013 2014 2015

América del Norte 7,684.20 8,968.00 10,311.00 11,544.90 12,929.00
Europa Occidental 2,662.50 3,190.30 3,775.10 4,290.30 4,813.20
Asia/Pacífico 768.3 974.8 1,210.90 1,450.80 1,693.90
Japón 379 434.8 500.80 565.30 629.10
América Latina 331.4 419.9 512.50 600.80 694.20
Europa Oriental 131.4 161.7 192.40 231.70 270.10
Medio Oriente/África 119.5 149.8 179.30 212.40 251.30
12,076.30 14,299.30 16,682.00 18,896.20 21,280.80
Figura 6.3 Tabla que muestra las proyecciones del mercado de SaaS por región
geográfica según datos de Gartner de 2011.
Los analistas Gartner pronostican que ingresos percibidos por SaaS pueden
llegar a $16,6 mil millones de dólares en 2013, con un incremento aproximado de
17.9 por ciento a partir de 2012. De acuerdo con Gartner, Inc. la entrega basada
en SaaS experimentará un crecimiento saludable hasta 2015, cuando se proyecta
que los ingresos en todo el mundo pueden llegar a $21,2 mil millones de dólares.
Existen distintos modelos que operan de manera similar al Software as a

Service y que comúnmente son englobados dentro del mismo concepto, como
ocurre con el modelo llamado Proveedor de Servicios de Aplicaciones o ASP (del
inglés Application Service Provider). El ASP es diferente al concepto de SaaS que
se tiene en la actualidad sobre servicios orientados a la Web, ya que ASP
especializa sus soluciones para cada cliente ofreciendo outsourcing para cada uno
de ellos, lo cual eleva sus costos y las disminuyen las ventajas ante el software
on-promises (ilustrado en la figura 6.3). Sin embargo la Asociación del Software y
de la Industria de la Información o SIIA (del inglés Software and Information
Industry Association) toma ambas definiciones (SaaS y ASP) y los engloba en el
término SaaS.
P á g i n a | 121
Figura 6.4 Grafico representativo del modelo ASP y SaaS
El mercado se ve obstaculizada por el desacuerdo sobre las características

intrínsecas de los servicios e incluso la terminología que se utiliza para
describir la aplicación de servicios. Las definiciones están en constante cambio,
azotadas por el establecimiento de nuevos modelos de negocios y empresas de
tecnología que ofrecen su propia visión del software como un servicio. El mercado
está inundado con acrónimos cada uno representando un enfoque
ligeramente diferente – Proveedor de Servicios de Aplicación (ASP),
Proveedores de Infraestructura de Aplicación (AIP), Servicio de Negocio en
Internet (IBS)… y más. Por lo tanto, para evitar la confusión la SIIA se refiere al
modelo general como el software como un servicio. 7
_________________________________________________________________
7 Software & Information Industry Association. (2001). Software as a Service: Strategic
Backgrounder [Software como Servicio: Antecedentes Estratégicos]. Washington DC,
Estados Unidos de América: [s.n]. p.4
P á g i n a | 122
A pesar que la SIIA sugiere que todos los conceptos sean englobados,
puesto que al final de cuentas todos ofrecen software a manera de servicio, es
importante diferenciar del modelo seguido por ASP y el concepto actual de SaaS
sobre servicios orientados a la Web, puesto que normalmente los ASP manejan
soluciones ya existentes de software on-promises adaptadas como servicios, y no
soluciones programadas originalmente para la Web como se hace con SaaS.
Algunas de las aplicaciones que corren o corrían en los ASP no están

preparadas para dar acceso a través de internet o no fueron diseñadas para dar
servicio a múltiples clientes de distintas empresas, es más, se ejecuta una
instancia por cada cliente del ASP.
La mayoría aplicaciones como servicio (modelo SaaS) si están diseñadas

para ofrecer la aplicación a varios clientes a través de una sola instancia, lo que se
conoce como multitenancy.
“Las modernas aplicaciones SaaS están construidas sobre tecnologías y

servicios que son altamente configurables y basadas en la Web. Estas diferencias
clave ofrecen SaaS y su usuarios de un entorno flexible, económico y dinámico en
el que el software puede ser entregado donde y cuando sea necesario.” 8
Algunos ejemplos de Software como Servicio son: Salesforce, Google Apps,

Microsoft Office 365, Marketo, TradeCard, y CallidusCloud.
_________________________________________________________________
8 A Brief History of SaaS [Una breve histiria sobre el Software como Servicio]. (s.f.). Recuperado el
20 de junio de 2013 de http://www.computerworld.com/pdfs/Service-Now-
BriefhistoryofSaaS.pdf.
P á g i n a | 123
6.6.1 Ventajas del Software como Servicio
Al cambiar el enfoque que se tenía para distribuir software local, se eliminan

las limitaciones que tiene la distribución tradicional, el uso y la actualización, como
podían ser los altos costes de redistribución, los costes que generaba en al
usuario para su actualización, como en caso de que hubiese un parche nuevo, o la
gran probabilidad de que el software lanzado en medio almacenable se copie
produciendo piratería.
Las ventajas del SaaS pueden ser observables desde dos perspectivas, la
perspectiva del cliente y la del proveedor:
6.6.1.1 Ventajas para el Cliente
 La responsabilidad de la operación del sistema recae en el proveedor de IT.

La garantía de disponibilidad de la aplicación y su correcta funcionalidad, es
parte del servicio que da la compañía proveedora del software.
 Los clientes no necesariamente deben de contar con un área especializada
de soporte para el sistema, por lo que se reducen sus costes y riesgo de
inversión.
 El servicio y atención continua del proveedor al cliente es necesaria para
que este último siga pagando el servicio.
 No es necesaria la compra de una licencia para utilizar el software, sino el
pago de un alquiler o renta por el uso del software.
 Se le permite al cliente completa flexibilidad en el uso de los sistemas
operativos de su preferencia, o al cual pueda tener acceso.
P á g i n a | 124
 Las entregas aplicaciones bajo este modelo son tendientes a mejoras

constantes puesto que el modelo vive de acuerdo a su capacidad para
mantener la lealtad de sus usuarios o clientes.
 Puede minimizar los costos de infraestructura.
6.6.1.2 Ventajas para el Proveedor
 El Software como Servicio orientado a la Web tiene un nivel de captación

de clientes nuevos mucho más grande que el software on-promises,
mediante modelos de negocios como el freemium y la capacidad de
difusión del Internet.
 Los esfuerzos y costos dedicados al mantenimiento del sistema se reducen
al centralizar la aplicación.
 Las incompatibilidades con las distintas plataformas en las que el cliente
‘ejecutará’ la aplicación son minimizadas, por lo cual no hay que programar
una aplicación para cada plataforma.
 La entrega de actualizaciones se hace más homogénea para la gran
mayoría de los clientes.
 Permite mejorar la retroalimentación, al mantener una relación más efectiva
entre el proveedor y el cliente que se ve reflejado en mejoras hacia el
sistema.
6.6.2 Inconvenientes del Software como Servicio
El SaaS también presenta ciertos inconvenientes que pueden ser

observados desde las perspectivas del cliente y del proveedor.
P á g i n a | 125
6.6.2.1 Inconvenientes para el Cliente
 Los clientes no tiene acceso directo a sus contenidos, ya que están

alojados en un lugar remoto, y en caso de no contar con mecanismos de
cifrado y control disminuye el índice de privacidad, control y seguridad que
ello supone, ya que la compañía TI podría consultarlos.
 Los clientes o usuarios no tiene acceso al programa, por lo cual difícilmente
puede hacer modificaciones a menos que exista una modalidad en los
contratos con la compañía proveedora.
 En algunos casos los proveedores pueden no permitirle al usuario migrar
sus datos a otro servicio utilizando el mismo programa, todo de acuerdo a
los contratos estipulados entre ambos.
 Si el servicio de Internet no está disponible por parte del ISP, el usuario no
tendrá acceso al programa, por lo que sus operaciones se verán afectadas
hasta que dicho servicio se restablezca.
 Si el proveedor del servicio quiebra, no existe una certeza de que los
usuarios puedan seguir utilizando sus servicios o su información, a menos
que se establezca en sus contratos.
6.6.2.2 Inconvenientes para el Proveedor
 Los márgenes de recuperación de inversión, suelen ser más lentos que los
del software on-promises, puesto que el cliente paga una renta que es
mucho menor a la adquisición inicial de un software local.
 Los SaaS demandan más niveles de seguridad puesto que la información
es centralizada.
 La responsabilidad aumenta ante fallos en un mismo sistema que es
utilizado por múltiples compañías o usuarios.
 El buen funcionamiento del sistema también depende de terceros, en
específico de la compañía proveedora de Internet.
P á g i n a | 126
El Software como Servicio, representa grandes ventajas tanto para los

proveedores como para los clientes y sus inconvenientes rápidamente se
van diezmando ante las mejoras tecnológicas en cuanto a seguridad y las
mejoras constantes en infraestructura por parte de los proveedores de
Internet, aunado a una sociedad cada vez más adaptada a las Tecnologías
de la Información y ‘conectada’ a la red, proporcionando así un mercado
bastante atractivo para la distribución de aplicaciones basadas en Web.
6.7 Freemium
Freemium es un modelo de negocios utilizado en aplicaciones SaaS,

mediante el cual el proveedor ofrece al usuario acceso a los servicios básicos de
una aplicación de manera gratuita, mientras que para acceder a las
funcionalidades más especializadas o avanzadas tiene que realizarse un pago.
Este modelo de negocios funciona de forma muy similar al shareware

utilizado para software instalado en el equipo del cliente (aplicación de escritorio),
en el cual, el usuario puede evaluar de forma gratuita el producto, pero con
limitaciones en el tiempo de uso o en con restricción de algunas de sus funciones.
Uno de los objetivos principales del freemium es demostrar al cliente

implícitamente porqué los servicios especiales prestados tienen que costar dinero.
P á g i n a | 127
Fue popularizado por Fred Wilson en 2006, con una publicación realizada
en su blog, donde describió su funcionamiento y solicitó sugerencias a sus
lectores acerca de cómo llamar a dicho modelo, iniciando con el texto siguiente:
“Ofrezca a sus clientes servicios de forma gratuita, posiblemente

financiados por publicidad o sin ella, adquiera una gran cantidad de clientes
gracias a la comunicación de boca en boca, a través de recomendaciones y
referencias, mercadotecnia, etc., y luego ofrezca servicios de paga con valor
añadido o una versión potenciada de los servicios a sus clientes de base.” 9
El modelo del freemium se adapta a las aplicaciones distribuidas bajo SaaS,

y permite la captación de nuevos clientes de una manera sencilla y atractiva
para ellos, dicho modelo puede ser aplicado en el sistema desarrollado en
esta tesis, ofreciendo un mes de prueba gratuita y posteriormente mostrar al
usuario todas las capacidades de la aplicación para obtener su lealtad.
_________________________________________________________________
9 My Favorite Business Model [Mi Modelo de Negocios Favorito]. (23 de marzo de 2006).
http://avc.blogs.com/a_vc/2006/03/my_favorite_bus.html.
CAPÍTULO VII
PUNTO DE VENTA
P á g i n a | 129
7.1 Introducción
Hoy en día tecnología nos ha ayudado a automatizar muchos procesos que

se hacían antes manualmente y como en consecuencia hemos ganado tiempo a
nuestro favor, esto lo podemos ver reflejado por ejemplo: en la rapidez para
realizar las ventas de un negocio, en la consulta de información de un sistema
informático, en la automatización de varios procesos al mismo tiempo etc.
En este capítulo haremos mención de los puntos de Venta en los negocios;

como ésta tecnología ha sido de gran ayuda en los negocios, desde grandes
supermercados hasta negocios locales el desarrollo de los sistemas de
información han sido de gran utilidad en las diferentes áreas de una organización
una de las principales económico financieras y administrativas pero el mejor
resultado es cuando los sistemas logran cubrir los objetivos y son redituables en
complemento con el ser humano.
Un punto de venta es el área comercial un lugar donde los clientes pueden

pagar sus compras. El término se utiliza normalmente para describir los sistemas
que las transacciones financieras sin precedentes. Esto podría ser una caja
registradora eléctrica o un sistema informático integrado que registra los datos que
comprende una transacción comercial para la venta de bienes o servicios.
P á g i n a | 130
7.2 Terminal Punto de Venta
Terminal Punto de Venta o POS (del inglés Point of Sale). “Es un software
que sirve para gestionar las ventas de las mercancías al por menor” 1. En ciertas
ocasiones, una caja registradora, una computadora o incluso aparatos de
tecnología táctil son utilizados para realizar las ventas de los negocios. La
mayoría del software POS se comunica con el módulo de inventario que ayuda a
mantener un equilibrio dentro del sistema.
Sus inicios se remonta a la década de los 70’s con el uso de cajas

registradoras que tenían instalado software propietario y con funcionalidades muy
limitadas. A mediados de los 70’s se implementa la arquitectura cliente-servidor en
cajas registradoras más avanzadas comunicadas a una base de datos
centralizada que permitía la sincronía del almacén en cada una de las terminales.
En los 80’s se crea el primer POS con interfaz gráfica y además contaba
con pantalla táctil a color, llamado Viewtouch.
En los 90’s fue lanzado un software de punto de venta para manejar ventas
al menudeo que se ejecutaba en Windows llamada T-Retail. Y a mediados de los
90’s se crean el estándares de comunicación para los dispositivos utilizados en los
POS por la Asociación para Estándares de Tecnologías en Minoristas o ARTS (del
inglés The Association for Retail Technology Standards)
__________________________________________________________________
1 What is a POS System? [¿Qué es un Sistema Terminal Punto de Venta?]. (s.f.). Recuperado el
11 de junio de 2013 de http://www.wisegeek.org/what-is-a-pos-system.htm#didyouknowout.
P á g i n a | 131
7.3 ARTS
La Asociación para Estándares de Tecnologías en Minoristas o ARTS (del

inglés The Association for Retail Technology Standards) ARTS pertenece a la
Federación Nacional de Minoristas quienes desarrollaron y mantienen el estándar
Unified POS.
“ARTS es una organización internacional dedicada a la reducción de los

costos de la tecnología a través de las normas. Desde 1993 ha creado normas de
aplicación exclusivamente a la industria minorista.” 2 Ha creado tres normas a fin
de hacer que la infraestructura de TI para los minoristas sea más barata, más
eficaz, más segura y más fácil de actualizar y usar.
1. Modelo de Datos
2. Unified POS
3. ARTS XML
7.3.1 Modelo de Datos
Es un modelo que sirve como guía para la construcción de bases de datos

en sistemas POS, el cual contiene los campos comúnmente utilizados en estos
sistemas. Proporciona a los minoristas y los vendedores una arquitectura de datos
estandarizada para el desarrollo de soluciones de negocio al por menor, y así
facilitar su escalabilidad y compatibilidad con sistemas de propósitos similares.
__________________________________________________________________
2 National Retail Federation [Federación Nacional de Minoristas]. (s.f.). Recuperado el 11 de junio
de 2013 de http://www.nrf-arts.org/.
P á g i n a | 132
7.3.2 Unified POS
“Es una especificación de arquitectura para interfaces de aplicación de los

dispositivos de POS que se utilizan en el entorno de venta al por menor. Esta
norma es a la vez independiente del sistema operativo y lenguaje neutro” 3
El Unified POS cumple con dos finalidades:
 Proveer una arquitectura para interfaces de comunicación entre los

dispositivos y aplicaciones de venta al por menor.
 Proporcionar un conjunto de comportamientos comunes de los dispositivos
comerciales que sean suficientes para apoyar una amplia gama de
soluciones POS.
El estándar Unified POS incluiye:
 Introducción a la arquitectura de periféricos Unified POS utilizados en

sistemas de ventas al por menor.
 Descripción de las interfaces para las funciones de los dispositivos.
 Terminología UML y los diagramas para cada categoría de dispositivos, que
describen las relaciones entre las clases / interfaces y objetos en el
sistema.
 Bases para la programación en C ++, Java, IDL, u otra tecnología Orientada
a Objetos para aplicar el diseño UML.
 Características de funcionamiento y detalles de las implementaciones que
son compatibles con la arquitectura Unified POS.
__________________________________________________________________
3 National Retail Federation. (2013). Unified POS [Punto de Venta Unificado]. Estados Unidos de
América: [s.n]. p 41.
P á g i n a | 133
El estándar Unified POS no incluirá:
 Especificaciones de la API para un lenguaje de programación en específico.

 Los componentes completos de software. Los proveedores de hardware,
proveedores de software, o terceros proveedores desarrollan y distribuyen
estos componentes.
 El mecanismo de certificación, lo que debe ser manejado
independientemente comités de estándares (como el OLE for Retail POS
(OPOS).
7.3.3 ARTS XML
ARTS XML es un esquema estandarizado que sirve para comunicar varias

aplicaciones que siguen los estándares de ARTS se entre sí para integrar la
información. Los esquemas completos son de dominio público, y están disponibles
en el sitio web de ARTS para su descarga y uso.
“…se basa en el modelo de datos ARTS para desarrollar esquemas XML

estándar y los conjuntos de mensajes para facilitar una aplicación a otra (de A a
A).” 4
Para el diseño de la base de datos del sistema, se seguirá parte de la

arquitectura para el modelado de datos de ARTS, el Unified POS sólo
servirá como referencia para el futuro del sistema ya que la delimitación del
sistema para esta tesis no contempla el uso de periféricos.
__________________________________________________________________
4 National Retail Federation [Federación Nacional de Minoristas]. (s.f.). Recuperado el 11 de junio
de 2013 de http://www.nrf-arts.org/.
P á g i n a | 134
Una de las mejores inversiones que puede hacer el dueño de cualquier

negocio es comprar software de negocio POS para llevar una mejor
administración de la organización. El tipo de software de negocios que necesita el
dueño de la organización es aquel que cubra las necesidades de la empresa
muchas de las tareas que se realizan manualmente ya son automatizadas por los
sistemas de punto de venta.
7.4 Terminal Punto de Venta en la Nube
Son sistemas de punto de venta en línea que almacenan datos en

servidores remotos en la nube, uno de los beneficios de la nube es que podemos
seguir ofreciendo el servicio a través de la web, atender peticiones en cualquier
momento y acceder a la información desde cualquier dispositivo fijo o móvil
ubicado en cualquier lugar.
También es importante mencionar que los sistemas POS basados en la

nube corren en línea, y son generalmente compatibles con cualquier dispositivo
con conexión a Internet, incluyendo computadoras de escritorio, portátiles o
tecnología inteligente en comparación a los sistemas POS tradicionales suelen
almacenar datos en el disco duro local, haciéndolos susceptibles al momento de la
pérdida de datos y bloqueos de cualquier equipo de cómputo.
P á g i n a | 135
7.4.1 Características de un Punto de Venta
Las características que un “sistema de punto de venta debe de tener para

mantener un control administrativo y operativo deben estar al alcance de cualquier
situación algunas de los atributos pueden ser:” 5
 Fácil de usar
 Registro de entradas y salidas de efectivo
 Ofrecer un precio al público en automático dependiendo el cliente
 Registro de retiro de efectivos al terminar una transacción al día
 Control y registro de Inventario
 Control de Almacén
 Un catálogo de productos
 Búsqueda de productos
 Catálogo de clientes
 Descuentos por clientes
 Registro de ventas (diarias, mensuales y anuales)
 Control y verificación de stock actual
Un sistema de punto de venta puede tener gran cantidad de

características, pero el principal atributo que puede tener es cubrir las necesidades
de los usuarios así como mantener un mejor control y organización de la
entidad. Es necesario conocer que es lo que realmente necesita mi negocio así
como también conocer los procesos que implica tener una entidad para poder
atacar y tener mejor retribuciones.
__________________________________________________________________
5 Universidad Tecnológica de Bahía de Banderas. Recuperado el 14 de junio de 2013 de
http://www.utbb.edu.mx/index.php/component/content/article/3-newsflash/123-ventajas-y-
desventajas-de-los-sistemas-de-punto-de-venta.html
P á g i n a | 136
Cuando hemos visto las características de un sistema de punto de venta

que se adecuen a mis necesidad entonces podemos enlistar los múltiples
beneficios que el software puede ofrecernos a nosotros usuarios.
7.4.2 Beneficios de un sistema de punto de venta
Los beneficios que podemos obtener son los siguientes:
 Mejor administración de los recursos

 Reducción de tiempos
 Mejor atención al cliente
 Agilizar procesos y obtenerlos en tiempo y forma
 Mayor control y visualización de nuestras ventas
 Mejor compresión de nuestra contabilidad
 Obtener reportes de ventas (mensuales y anuales)
 Actualización de información inmediata
Beneficios podemos enumerar un sin número pero el mejor benéfico lo

obtendremos reflejado en la parte económico financiero al demostrar que la
automatización de la información pude generar grandes mejoras de una forma
más rápida y sencilla de utilizar.
CAPÍTULO VIII
METODOLOGÍA DE DESARROLLO DE SOFTWARE ÁGIL
P á g i n a | 138
8.1 Introducción
Las Metodologías de Desarrollo de Software definen los procedimientos a

seguir para realizar determinadas tareas relacionadas con los procesos de
toma de requerimientos, análisis, diseño, codificación, implementación,
pruebas y cada una de las actividades involucradas en el proceso de creación
del Software. Existen diferente metodologías que varían según el alcance que
proporciona al desarrollo de software.
El inicio del desarrollo masivo de software trajo consigo la necesidad de

encontrar mejores prácticas de desarrollo y de distribución de experiencia obtenida
a través de la práctica para generar una retroalimentación constante. De esta forma
nacieron las Metodologías de desarrollo de Software impulsadas por universidad y
grandes empresas.
Una forma de clasificar a las metodologías es por metodologías tradicionales

que siguen procesos mucho más controlados y por metodologías agiles que priman
la libertad del equipo y la comunicación con el cliente. Esto no quiere decir que una
sea mejor que otra, simplemente cada una es adecuada según el tipo de desarrollo
en específico a realizar.
P á g i n a | 139
8.2 Metodologías Tradicionales
En general este tipo de metodologías utilizan procesos definidos y la

recopilación de información se realiza al inicio del proyecto, son metodologías
estrictas y poseen cierta resistencia al cambio durante el desarrollo, la
comunicación con el cliente es por medio de reuniones establecidas. Son
recomendadas para equipos de trabajo con gran cantidad de personal, algunas de
las metodologías tradicionales son:
 Programación estructurada sol de 1969.

 SSADM (Structured Systems Analysis and Design Methodology) de 1980.
 RUP (Rational Unified Process) de 1999.
Estas metodologías siguen procesos de desarrollo de software

controlados y rigurosos, opinión que provenía, fundamentalmente de la
comunidad de ingenieros de software de los años 80’s que desarrollaban
grandes sistemas de larga vida y con numerosos programas individuales.
Contaban con equipos de trabajo muy grandes incluso equipos de distintas
compañías y dispersos geográficamente.
Este tipo de metodología aún es ampliamente utilizada para el desarrollo de

sistemas críticos en los cuales el control riguroso es fundamental, no se trata de una
metodología anticuada, simplemente sigue enfoques más rígidos o “pesados” de
desarrollo que se centran demasiado en la planificación y que son difícilmente
aplicables a sistemas de negocios pequeños.
P á g i n a | 140
8.3 Metodologías Ágiles
Cuando el enfoque de las metodologías tradicionales es aplicado a sistemas

pequeños y de tamaño medio, el esfuerzo invertido en la planificación es tan grande
que domina sobre el objetivo principal del sistema a realizar. Debido a ese
descontento en los años 90 se proponen los nuevos métodos agiles.
En general los Métodos Ágiles de ingeniería del software están basados en

el desarrollo iterativo e incremental, donde los requerimientos y soluciones
evolucionan mediante el transcurso del desarrollo y donde la colaboración
de grupos auto-organizados y multidisciplinarios es fundamental.
“Los métodos agiles universalmente dependen de un enfoque iterativo para

la especificación, desarrollo y entrega del software y principalmente fueron
diseñados para apoyar al desarrollo de aplicaciones de negocio donde los
requerimientos del sistema normalmente cambian rápidamente durante el proceso
de desarrollo” 1
En las Metodologías Agiles la recopilación de información se da durante todo

el proyecto, no sólo al inicio, siempre está preparada para cambiar durante el
desarrollo, y el cliente es visto como un integrante muy importante en el equipo.
_________________________________________________________________
1 Sommerville I. (2005). Ingeniería del Software (María Isabel Alfonso Galipienso trad.). (7a ed.).
Madrid, España: Pearson. p 362.
P á g i n a | 141
El software no se desarrolla en su totalidad para su uso en un sólo ciclo

(iteración), sino que es entregado en una serie de incrementos, en los cuales se
incluyen nuevas funcionalidades del sistema.
El tamaño del equipo es una consideración importante. La inmensa mayoría

de los proyectos se realizan por empresas o equipo pequeños de 1 a 10 personas
donde las metodologías tradicionales son difíciles de aplicar y las metodologías
agiles se adaptan perfectamente.
Algunas metodologías agiles son:
 Agile Unified Process (AUP).

 Crystal Clear.
 Lean Software Development (LSD).
 Open Unified Process (OpenUP).
 Programación Extrema (XP).
 Método de desarrollo de sistemas dinámicos (DSDM).
 Scrum.
Todos los métodos agiles están basados en los principios expuestos en el

Manifiesto por el Desarrollo Ágil de Software, resumiendo los principios de todas las
metodologías ágiles pueden distinguirse 5 principales:
1. Participación del cliente: Los clientes deben estar completamente

involucrados en los procesos de desarrollo. Su papel es proporcionar y
priorizar nuevos requerimientos y sobre todo la evaluación de cada una de
las iteraciones del sistema.
P á g i n a | 142
2. Entrega Incremental: El software se desarrolla en incrementos, y en cada

uno, nuevamente el cliente especifica los requerimientos.
3. Personas, no procesos: Se da libertad a las personas de desarrollar sus
propias formas de trabajar explotando sus propias habilidades.
4. Aceptar el cambio: Se toma en cuenta, desde el inicio, que los
requerimientos están en constante cambio, por lo que el sistema debe
contemplar la flexibilidad para poder adoptar sin problema dichos cambios.
5. Mantener la Simplicidad: Se dejan a un lado los estrictos formalismos para
favorecer la simplicidad tanto en el software a desarrollar en su propio
proceso de creación, eliminando toda la complejidad posible.
El manifiesto completo puede ser consultado en el Anexo C Manifiesto Ágil
La documentación en las metodologías ágiles es muy ligera puesto que la

filosofía misma de ésta metodología se centra más en los procesos funcionales para
el cliente, por lo que la documentación extensa resulta un proceso que retrasa la
entrega de incrementos de software. Esto no quiere decir que no se deba
documentar para agilizar aún más el proceso de desarrollo, es necesario
documentar algunos módulos que ayuden a los futuros programadores a dar
mantenimiento o actualizaciones con mayor facilidad.
“… Aunque el manifiesto ágil no rechaza el que se documente en los proyectos,

si antepone otras muchas cosas frente a documentar, y muchos proyectos han
interpretado esto como que en un proyecto ágil no se debe escribir ningún
documento. Y esto es un error, y muchos proyectos, con los años, han sufrido
mucho este problema, e incluso se han visto imposibilitados a la hora de cambiar
de proveedor de desarrollo software.” 2
_________________________________________________________________
2 Metodologías ágiles. (s.f.). Recuperado el 23 de junio de 2013 de
http://www.javiergarzas.com/metodologias-agiles.
P á g i n a | 143
.
Por contrario a lo que pueda pensarse los Métodos Ágiles si pueden
desarrollarse conforme a modelos de procesos para certificaciones ISO 15504.
El ISO 15504 Modelo de evaluación (y mejora) de procesos software o SPICE

(Software Process Improvement Capability Determination) es una adaptación para
la evaluación de procesos en PYMEs y pequeños grupos de desarrollo software,
dicha evaluación se lleva a cabo por niveles de madurez.
El ISO 15504 está alineado con las metodologías ágiles (SCRUM, XP, etc.),
también con las guías ISO/IEC 29110 (Lifecycle Profiles for Very Small Enterprises)
y con otras normas muy extendidas en el sector como la ISO/IEC 27001 (seguridad
de la información) y la ISO/IEC 20000 (gestión del servicio TI).
Figura 8.1 Diagramas representativos de las metodologías tradicional en cascada y ágil.

P á g i n a | 144
Si bien algo que distingue enormemente a las metodologías ágiles son sus
ciclos iterativos, éstos no son propios de los métodos ágiles puesto que también
existen metodologías tradicionales que utilizan procesos iterativos dentro de su
‘estructura’ general, como por ejemplo RUP.
Figura 8.2 Diagramas representativos de las metodologías tradicional RUP y ágil.
La metodología RUP es considerada como una metodología tradicional

debido a su estricta documentación y seguimiento en cada uno de sus procesos,
además de estar diseñado para el desarrollo de sistemas críticos con equipos de
trabajo grandes. RUP también maneja iteraciones pero estas son internas entre el
diseño, construcción y pruebas, pero no maneja entregas de incrementos o piezas
de software funcionales al cliente.
P á g i n a | 145
Puesto que para la elaboración del sistema que abarca esta tesis, se cuenta
con un equipo de 2 personas y un tiempo corto de desarrollo, se ha optado
por seguir una metodología de desarrollo ágil, además de que dicha
metodología permite que proyecciones del sistema previstos se lleven a
cabo con nivel mayor de adaptación, ante nuevas tecnologías o nuevos
requisitos.
8.4 Metodologías Tradicionales vs Metodologías Ágiles
Como se mencionó anteriormente ninguna es mejor que la otra, ni las

metodologías tradicionales son anticuadas, pesadas y suponen un “todo o nada”, ni
las metodologías ágiles son mejores porque son más modernas o son peores
porque carecen de disciplina. Aun así pueden distinguirse ciertas diferencias entre
ellas:
Ágil Tradicional
Especialmente preparados para el
Cierta resistencia al cambio
cambio durante el proyecto
Métodos impuestos por el propio Métodos impuestos externamente
equipo (empresa)
Procesos menos controlados, con
Procesos mucho más controlados y
pocos principios donde el cliente
con numerosas normas
es parte del equipo de desarrollo
Grupos pequeños (menos de 10) Grupos grandes y distribuidos
Pocos artefactos (módulos) Más artefactos (módulos)
Pocos roles (2) Más roles y tienden a no cambiar
Menos énfasis en la La documentación de software es
documentación de software esencial.
Figura 8.3 Tabla comparativa entre Metodología Ágil contra una Metodología Tradicional
P á g i n a | 146
La elección del tipo de metodología va en relación con los recursos, el tiempo,

el personal, el tipo de sistema y el tamaño del mismo. Además no es necesario
apegarse a una sola metodología puesto que puede seguirse una combinación
creando una metodología hibrida que conjunte las características de 2 o más
metodologías.
8.5 Programación Extrema
Programación extrema o eXtreme Programming (XP) es una metodología

de desarrollo de la ingeniería de software basada en los principios de las
metodologías agiles de acuerdo a el manifiesto ágil.
Se trata de una metodología ágil de desarrollo de software creada por Kent

Beck en 1996 basada en simplicidad, comunicación, valor y el respeto. Cada
colaborador es una parte integral del equipo. La satisfacción del cliente es
imprescindible y para ello al mismo cliente se le toma en cuenta como un
colaborador primordial en el equipo de desarrollo. Proporciona incrementos del
sistema que satisfacen las necesidades del cliente justo cuando este lo necesita.
“La programación Extrema (XP) es posiblemente el método ágil más

conocido y ampliamente utilizado. El nombre fue acuñado por Beck, debido a que
el enfoque fue desarrollado utilizando buenas prácticas reconocidas, como el
desarrollo iterativo y con la participación del cliente en niveles extremos” 3
_________________________________________________________________
Madrid, España: Pearson.p 364.
P á g i n a | 147
Los programadores extremos se comunican constantemente con sus clientes

y compañeros programadores. Mantienen su diseño simple y limpio. Reciben
retroalimentación probando fragmentos del sistema a partir del primer día. Los
programadores extremos son capaces de responder con valentía a las necesidades
y tecnologías cambiantes.
Figura 8.4 Gráfico de la estructura de Programación Extrema (XP) con tiempos aproximados
Esta metodología implica varias prácticas, algunas presentes en la mayoría

de las metodologías ágiles.
Pequeñas liberaciones: En cada liberación es entregado el mínimo conjunto

útil de funcionalidad que proporcione valor de negocio se desarrolla primero. Las
entregas posteriores añaden funcionalidad a la primera entrega.
P á g i n a | 148
Diseño simple: Sólo se lleva acabo el diseño necesario para cumplir con los
requerimientos actuales.
Desarrollo previamente probado: Se utiliza un sistema de pruebas de

unidad automatizado para escribir pruebas para nuevas funcionalidades antes de
que éstas se implementen.
Refactorización: Reescribir ciertas partes del código para aumentar su

legibilidad y facilitar su mantenimiento pero sin modificar su comportamiento.
Programación en parejas: Es recomendado que el desarrollo se lleve a

cabo por dos personas de un mismo puesto. Los desarrolladores trabajan en todas
las áreas del sistema, de modo que no desarrollen islas de conocimientos y todos
los desarrolladores posean todo el código.
Integración continua: En cuanto acaba el trabajo en una tarea, se integra

en el sistema entero. Después de la integración, se deben pasar al sistema todas
las pruebas de unidad.
Ritmo sostenible: No son aceptables grandes cantidades de horas de

trabajo, ya que a menudo el efecto que tienen es que reduce la cantidad de código
y la productividad a medio plazo.
P á g i n a | 149
La prioridad de los requerimientos es especificada y establecida por el cliente.

“Los requerimiento no se especifican como una lista de funciones requeridas del
sistema. Más bien, los clientes del sistema son parte del equipo de desarrollo y
discuten escenarios con otros miembros del equipo… El equipo de desarrollo
intentará entonces implementar ese escenario en una entrega futura del software” 4
Es posible que se lleguen a construir varias veces al día nuevas versiones

del software, en cada versión el programador debe ejecutar todas las pruebas
automatizadas existentes además de las pruebas de las funcionalidades nuevas.
Uno de los principios generales de las metodologías ágiles es su diseño

preparado para el cambio, sin embargo, la Programación Extrema no toma muy en
cuenta este principio partiendo del hecho de que diseñar para el cambio es a
menudo un esfuerzo inútil puesto que la inmensa mayoría de los cambios previstos
nunca se materializan.
En caso de existir un cambio imprevisto en la programación extrema se

maneja como principio la refactorización, en la que se busca que el software siempre
deba ser fácil de entender para ayudar a realizar posibles mejoras de software y
estas sean implementadas inmediatamente.
XP fue elegida principalmente porque se adapta a la escalabilidad prevista en

las proyecciones futuras del sistema, además de adecuarse a la cantidad de
individuos participantes y el tiempo de desarrollo.
_________________________________________________________________
Madrid, España: Pearson.p 365.
P á g i n a | 150
8.5.1 Ciclo de Vida de Programación Extrema
Figura 8.5 Gráfico representativo del ciclo de vida de la Programación Extrema (XP)
El proceso de análisis se realiza en estrecha relación con el cliente quien

escribe con sus propias palabras que es lo que desea hacer con el sistema, a este
documento se le conoce como historias de usuario.
El programador formula requerimientos en base a las historias de usuario y

se lleva a cabo un spike, que es un experimento dinámico de código, realizado para
determinar cómo podría resolverse un problema. Es la versión ágil de la idea de
prototipo. Se lo llama así porque “va de punta a punta, pero es muy fino”, una vez
que se tiene confianza del plan de liberación se procede al diseño.
Las fases de diseño, construcción y pruebas forma están en constante

iteración ante nuevos requerimientos o errores de programación, una vez superados
éstos, es entregado un incremento que está sujeto a la aprobación del cliente si
contiene errores se regresa a la fase de pruebas, diseño o construcción según se
requiera, sino, se procede con la nueva iteración.
P á g i n a | 151
8.5.2 Desarrollo Incremental
También llamado Desarrollo iterativo y creciente es un proceso de desarrollo

de software que implica producir y entregar el software en incrementos en cada
iteración de esta forma los incrementos iniciales del sistema se pueden entregar ya
con funcionalidades de alta prioridad para que el cliente pueda aprovechar el
sistema.
En cada iteración, se realizan cambios en el diseño y se agregan nuevas

funcionalidades y capacidades al sistema. De manera general consiste en 2 etapas:
 Etapa de inicialización: El objetivo de esta etapa es crear un

producto con el que el usuario pueda interactuar, y por ende
retroalimentar el proceso.
 Etapa de iteración: Involucra el rediseño e implementación de una
tarea, y el análisis de la versión más reciente del sistema.
El desarrollo iterativo es una característica básica de las metodologías agiles

pero no es nueva ya que los sistemas de negocio se han desarrollado de forma
iterativa durante muchos años utilizando técnicas de desarrollo rápido de
aplicaciones (RAD) como:
 Lenguajes de programación de Bases de Datos (como SQL)

 Generadores de Interfaces
 Generadores de Informes
P á g i n a | 152
8.5.3 Programación en Parejas
Programación en Parejas (o Pair Programming en inglés) es una práctica en

la que participan 2 individuos (programadores) que combinan esfuerzos de
desarrollo en un sitio de trabajo. Suelen distinguirse 2 roles:
1. Conductor o piloto: Es quien escribe el código, no escribe a manera

de dictado sino que conjunta sus propios conocimientos y los
enriquece con la ayuda táctica por parte del navegante, a manera de
retroalimentación.
2. Observador o navegante: Dirige al conductor con la finalidad de
mejorar el código, también debe contar con una computadora, no para
desarrollar, pero sí para consultar documentación del sistema, fuentes
externas, el navegante cumple el papel de guía.
Estos roles suelen cambiarse entre ambos de manera constante cada cierto
tiempo o cada prueba de unidad. Es bueno cambiar de parejas frecuentemente
porque mejora la distribución de conocimiento entre el equipo.
Diversos estudios han demostrado que la programación en parejas eleva la

productividad en el desarrollo de sistemas, en algunos casos llega a elevarse la
productividad a más del doble.
P á g i n a | 153
"Laurie Williams de la universidad de Utah en Salt Lake City ha demostrado

que los programadores emparejados son solamente 15% más lentos de dos
programadores trabajando independientemente, pero producen 15% menos
errores. Y ya que la prueba y depuración son a menudo muchas veces más costosa
que la programación inicial, esto es da un resultado impresionante." 5
Dos personas participarán en el desarrollo del sistema, mientras una persona

programa la otra persona está atenta a los módulos y tiempos, esto con la
finalidad de tener siempre un programador
8.5.4 Integración Continúa
Es una serie de prácticas que consisten en hacer integraciones automáticas

de un proyecto lo más a menudo posible para así poder detectar fallos cuanto antes,
con ayuda de gestores de versiones.
Un gestor de versiones o controlador de versiones o SVC (del inglés System

Version Control) administra los diversos cambios que se realizan sobre los
elementos de algún producto (software) o una configuración del mismo. Una
versión, revisión o edición de un producto, es el estado en el que se encuentra dicho
producto en un momento dado de su desarrollo o modificación.
_________________________________________________________________
5 Team spirit agility counts [Espíritu de Equipo, la agilidad cuenta]. (20 de septiembre de 2001).
Recuperado el 23 de junio de 2013 de http://www.economist.com/node/779429.
P á g i n a | 154
También para lograr la integración continua se utilizan herramientas de

gestión de dependencias, que permiten declarar las bibliotecas dependientes y
los instala en el proyecto, para mantener una sincronía entre todos los participantes
del proyecto en sus equipos.
“La integración continua es una práctica de desarrollo de software donde los

miembros de un equipo de integrar su trabajo con frecuencia, por lo general cada
persona se integra diariamente por lo menos.” 6
Para lograr la integración

continúa en el desarrollo del
sistema, se utilizarán Github
como gestor de versiones y
Composer como herramienta
de gestión de dependencias.
Figura 8.6 Gráfico representativo del funcionamiento de SVC en la nube
_________________________________________________________________
6 Continuous Integration [Integración continúa]. (01 de mayo de 2006). Recuperado el 25 de junio
de 2013 de http://martinfowler.com/articles/continuousIntegration.html.
P á g i n a | 155
8.5.5 Artefactos
Durante el transcurso del ciclo de vida de la metodología eXtreme

Programming pueden ser utilizados algunos artefactos o documentos, que sirven
como referencia de las tareas a realizar, estos suelen escribirse a mano en
pequeñas hojas de papel autoadhesivas que son colocadas normalmente en un
pizarrón a la vista de todos los miembros del equipo, o pueden escribirse de manera
digital en algún procesador de textos.
Historias de usuario: Historias de usuario se utilizan las metodologías de

desarrollo ágil de software como la base para la definición de las funciones de un
sistema. Describen el comportamiento del sistema, empleando la terminología del
cliente sin lenguaje técnico, capturando el "quién", "qué" y "por qué" de un requisito
de forma sencilla y concisa. Se realiza una por cada característica principal del
sistema, se emplean para hacer estimaciones de tiempo y para el plan de
lanzamientos.
Las historias de usuario son una manera rápida de manejar los

requerimientos del cliente sin tener que crear documentos de requisitos formales y
sin llevar a cabo las tareas administrativas relacionadas con el mantenimiento de
los mismos.
Las historias de usuario están compuestas por elementos esenciales:
 Tarjeta: Documento física donde se almacena suficiente información

para identificar y detallar la historia.
 Conversación: Una charla entre el cliente y los programadores donde

se discute la historia de usuario para ampliar los detalles.
P á g i n a | 156
Generalmente el tiempo de cada historia de usuario es de 10 horas a un par

de semanas. Las estimaciones que sean mayores a dos semanas deben ser
divididas en varias historias. Para el contenido de la tarjeta no existe una regla
estándar que describa los componentes de una historia de usuario, sin embargo
existen campos comúnmente utilizados:
 Número de historia de usuario, comúnmente es un número

incremental.
 Nombre descriptivo de la historia de usuario.
 Usuario Involucrado en la historia de usuario.
 Prioridad, expresado mediante un campo escrito en la tarjeta o

representado por el color de fondo de la misma tarjeta.
 Iteración Asignada, representa
 Descripción general de la historia de usuario.
 Observaciones si es que existen de la conversación con el cliente, u

otros aspectos importantes.
Se acostumbra escribir las historias de usuario en cuadros de papel

adherible de distintos colores que indiquen a simple vista la prioridad y
pegados en un pizarrón dividido en 3 secciones “no hecho”, “en proceso” y
“terminado”, sin embargo las notas también pueden ser capturadas en formatos
digitales como tablas de hojas de cálculo o en documentos de procesadores de
texto y organizados de la forma que más cómoda resulte para los programadores.
Utilizada: Al inicio de cada iteración

P á g i n a | 157
Figura 8.7 Formato de artefacto Historia de usuario para XP
Pruebas de Aceptación: Permite confirmar que la historia ha sido

implementada correctamente, al terminar la prueba de aceptación de ser necesario
se genera una nueva historia de usuario para corregir los errores que se hallan
presentado o para explicar un nuevo requerimiento.
Utilizada: Al terminar una historia de usuario y en la fase de pruebas

P á g i n a | 158
Caso de Aceptación de Pruebas

Numero de Prueba: Número de la prueba (incremental)
Referencia: Historia de Usuario y (No.)
Tipos de datos insertados, escenarios

Condiciones de Ejecución: posibles a los que esta expuesto el sistema
Datos en especifico, utilizados para la

Entrada/Pasos de ejecución prueba
Resultado Esperado: De acuerdo con la logica de programación
Evaluación de la Prueba: (Éxitosa/Fallida)
Figura 8.8 Formato de artefacto Caso de Aceptación de Pruebas para XP
Este artefacto al igual que las historias de usuario puede documentarse en

papel adhesivo en formatos digitales como el mostrado en la figura 8.8.
Task Card (tarea de ingeniería): Las task card se usan para describir las
tareas que se realizan sobre el proyecto. Las tareas pueden ser: desarrollo,
corrección, mejora, etc. Estas tareas tienen relación con una historia de usuario; se
especifica la fecha de inicio y fin de la tarea, se nombra al programador responsable
de cumplirla y describimos que se tratara de hacer en la tarea.
Utilizada: Durante las fases iterativas de diseño y construcción.

P á g i n a | 159
Tarea de Ingeniería
Desarrollo / Corrección
Número de Tarea: No de Tarea Tipo de Tarea:
/ Mejora
Nombre de Tarea: Campo Opcional si exite un nombre descriptivo
Fecha pueda incluir Fecha pueda incluir

Fecha Inicio: hora
Fecha Fin: hora
Referencia: Nombre Historia de Usuario y (No.)

Programador Nombre del programador responsable puede incluirse el nombre del
Responsable: programador secundario (programación en parejas)
Descripción del trabajo de desarrollo más especifico que en la historia
Descripción: de usuario
Figura 8.9 Formato de artefacto Tarea de Ingeniería para XP
Las tareas de ingeníera se utilizan para especificar trabajos de desarrollo

basadas en las historias de usuario, una historia de usuario puede tener varias
tareas de ingeniería o no tener ninguna en caso de que la historia de usuario sea
muy específica y detalle claramente la tarea del programador o en la conversación
con el cliente se hallan recalcado todas las especificaciones necesarias para que el
programador pueda empezar a trabajar.
El artefacto más utilizado es la historia de usuario, el resto de los

artefactos suelen ser utilizados de forma opcional, la metodología es tan
flexible que incluso permite cambiar el formato de cada artefacto, agregando
más campos si es requerido. Estos artefactos vienen a sustituir la laboriosa
documentación en comparación con las metodologías tradicionales.
P á g i n a | 160
8.6 Programación Extrema y UML
Programación extrema cuenta con sus propios documentos o artefactos que

sirven para describir el funcionamiento del sistema a realizar, sin embargo también
es posible el uso de UML en Programación Extrema, puesto que la metodología es
sumamente flexible y no está peleada con ese tipo de documentación, siempre y
cuando ésta no absorba o interfiera con los objetivos de las metodologías ágiles,
principalmente la de dar prioridad a los procesos.
Ciertos diagramas UML resultan de suma utilidad, principalmente cuando se

explica el funcionamiento a un nuevo integrante del equipo que trabajará con
determinado modulo del sistema, el diagrama provee una imagen general respecto
al funcionamiento y permite una familiarización más rápida.
El uso de UML es completamente opcional, pero existen algunos diagramas

UML que suelen utilizase con mayor frecuencia independientemente de la
metodología estos diagramas son:
 Diagrama de clases (Sólo de las clases más importantes)
 Diagrama de navegación (General del sistema)
Además de los diagramas UML también es común realizar gráficos que

representen la estructura de la base de datos, generalmente para las bases de datos
relacionales se utiliza:
 Diagrama de base de datos Entidad-Relación o E-R

CASO PRÁCTICO
DESARROLLO DE UN SISTEMA PUNTO DE VENTA EN LA NUBE
Todo el trabajo de investigación de esta tesis puede ser visto como un estudio de
mercado, a pesar de ello es necesario recalcar a manera de resumen los puntos
clave que proporcionen un panorama general del contenido de esta investigación y
añadiendo datos de mayor interés comercial.
P á g i n a | 162
1 Estudio de Mercado
1.1 Análisis del consumidor
Los ingresos totales percibidos en 2008 por las empresas dedicadas al

comercio fueron aproximadamente de 5, 535,086.00 millones de pesos en México.
De los cuales 3, 284,191.00 millones provienen de las PyMES comerciales y más
en específico, 657,997.00 millones provienen de las PyMEs dedicadas al comercio
al por menor de las principales ramas. 1
Ingresos de las empresas del sector comercial en México de

2008
Empresas Grandes comerciales

(al por mayor y por menor)
MiPyMES comerciales de las

10% principales ramas al por menor
30%
41% 59%
MiPyMES comerciales de las
19% principales ramas al por mayor
MiPyMES comerciales
restantes (al por mayor y por
menor)
Figura C.1 Ingresos de las empresas del sector comercial en México 2008 de acuerdo con datos
del último censo económico de 2009 del INEGI
__________________________________________________________________
Unidos Mexicanos: [s.n]. pp. 73-74.
P á g i n a | 163
Las principales ramas de las MiPyMES dedicadas al comercio al por menor

son las que a continuación se enlistan:
Ingresos
Rama
(millones de pesos)
Abarrotes y alimentos al por menor.
77,006.00
Tiendas de autoservicio al por menor.

569,612.00
Ropa y accesorios de vestir al por menor.

342,351.00
Ferretería, tlapalería y vidrios al por menor.

313,473.00
Papelerías, libros y revistas al por menor.

121,041.00
Artículos para el cuidado de la salud al por menor.

40,005.00
Combustibles, aceites y lubricantes al por menor.

56,230.00
Tiendas departamentales al por menor.

138,279.00
Figura C.2 Ingresos de las principales ramas de comercio al por menor de acuerdo con INEGI
Porcentaje de ingresos de las principales ramas del comercio al

por menor de las MiPyMES en México 2008
Abarrotes y alimentos al por menor.
3% Tiendas de autoservicio al por menor.

8%
3% 5% Ropa y accesorios de vestir al por menor.
7% Ferretería, tlapalería y vidrios al por

34% menor.
Papelerías, libros y revistas al por menor.
19%
Artículos para el cuidado de la salud al
por menor.
21%
Combustibles, aceites y lubricantes al por
menor.
Tiendas departamentales al por menor.
Figura C.3 Porcentaje de ingresos de las principales ramas del comercio al por menor de las
MiPyMES en México 2008 de acuerdo con datos del último censo económico de 2009 del INEGI
P á g i n a | 164
Las grandes empresas cuentan con ventajas como la concentración de una alta
gama de productos, la compra de mercancía en grandes cantidades y el uso de
herramientas tecnológicas que les permiten la automatización de sus operaciones de
compra, venta y logística, que se ven reflejadas en una disminución de sus costos, lo
cual le permite ofrecer precios más competitivos y acaparar gran parte del mercado.
Una brecha comercial y competitiva con la que se topan las MiPyMEs (y

principalmente las microempresas) contra las grandes empresas, radica en la tecnología
utilizada para realizar sus operaciones y obtener un mayor control y administración de
sus negocios. Estos impedimentos tecnológicos se han ido diezmando, desde hace dos
décadas aproximadamente (mediados de los 90’s).
Hoy en día miles de empresas ya usan la web como vía de contacto con más de
2 mil millones de posibles clientes en el mundo, más de 40 millones de ellos están en
México y más de 230 millones en América Latina. De acuerdo con diversas consultas
realizadas en México estos son los usuarios que utilizan internet en el país:
Total
Estudio Fecha
(millones de usuarios)
AMIPCI2 45.1 dic-12
WIP México3 52.3 ago-12
INEGI4 40.9 nov-12
IWS5 42.0 jun-12
______________________________________________________________________
2 Hábitos de los Usuarios de Internet en México 2013. (2013). Recuperado el 25 de junio de 2013 de
http://www.amipci.org.mx/?P=editomultimediafile&Multimedia=348&Type=1.
3 Estudio 2012 de hábitos y percepciones de los mexicanos sobre Internet y diversas tecnologías
asociadas. (2012). Recuperado el 25 de junio de 2013 de http://www.wip.mx/estudios_wip.html.
4 Usuarios de las tecnologías de información 2001 a 2012. (29 de noviembre de 2012). Recuperado el 25
de junio de 2013 de
http://www3.inegi.org.mx/sistemas/sisept/default.aspx?t=tinf204&s=est&c=19437.
5 Internet Usage Statistics, Population and Telecom Reports for the Americas. (30 de junio de 2012).
Recuperado el 25 de junio de 2013 de http://www.internetworldstats.com/stats2.htm.
P á g i n a | 165
Basado en las necesidades de las empresas dedicadas al comercio al por menor

especialmente aquellas clasificadas como MiPyMEs y los avances tecnológicos y de
infraestructura con los que se cuentan hoy en día (marzo de 2013) se propone la creación
de un sistema que ayude a los usuarios con las operaciones de sus negocios,
especialmente aquellos relacionados con la compra, venta e inventariado de mercancía,
mediante una sistema informático basado en tecnologías Web.
De lo anterior podemos concluir que la segmentación de mercado es la siguiente:

MiPyMEs del sector comercial al por menor.
Para complementar este estudio ver:
CAPÍTULO I MIPYMES DEL COMERCIO AL POR MENOR
1.2 Análisis de Competencia
La plataforma elegida (Web) incrementa la gama de competidores en el mercado,

puesto que dicha plataforma permite la captación de nuevos clientes en todo el mundo.
Por tal motivo sólo serán analizados lo competidores con las siguientes características:
 Que ofrezcan sistemas con el mayor número de características similares al

propuesto.
 Que aparezca dentro de los principales resultados de los buscadores web
más populares (google, yahoo y bing) utilizando palabra claves como: POS,
punto de venta, online, nube, web, México, español, y sus combinaciones
resultantes.
Solo se compararán los precios de sus paquetes o soluciones más básico o

equiparables a las funcionalidades del sistema propuesto.
P á g i n a | 166
COMPETENCIA POS WEB
Precio
Producto Español Pesos1 País Tecnologías Pros Contras Freemium Página Web
Básico2
Sucursales
UI Sencilla,
en Estados
Extensiones para
Unidos,
PHP, Comercio Precios no
Nueva No (30 días
Vend Si Si $35/m
Zelanda,
JavaScript, Electrónico accesibles para el
de prueba)
http://www.vendhq.com/
HTML5 (shopify), App para mercado mexicano
Reino
iOs, integración de
Unido y
hardware POS
Australia
UI Amigable,
graficas,
No está en español
estadísticas,
Imonggo No No $30/m Texas, EUA Desconocido
funcionamiento
ni maneja peso Si http://www.imonggo.com/
mexicano
offline, integración
de hardware POS
UI anticuada, no
Precio accesible,
PHP Nueva PHP, está en español ni No (14 días
No No $29/m integración con http://www.phppointofsale.com
pointofsale York, EUA JavaScript
hardware POS
maneja peso de prueba)
mexicano
Precios muy
UI Atractiva y costosos, no está
Amigable, gráficos, en español ni
Montreal,
LightSpeed No No $79/m
Canadá
Desconocido estadísticas, app maneja peso No http://www.lightspeedretail.com
para iOS, integración mexicano,
de hardware hardware propio y
costoso
P á g i n a | 167
UI anticuada,
registro
Modelo de
adicionales de
freemium muy
California, tiendas son
Posteria No No $77/m
EUA
Desconocido accesible,
costosos, no está
Si http://www.posterita.org
integración de
en español ni
hardware POS
maneja peso
mexicano
España, Especialización
On Dirigido a grandes
Openbravo Si Si
Demand
India, EUA, Desconocido regional, UI sencilla,
minoristas
No http://www.openbravo.com/
México precio ajustable
Manejo de
No está sujeto a un
comisión por
pago fijo mensual,
Comisión Estocolmo, ventas que eleva el
iZettle Si Si
de ventas Suecia
Desconocido cuenta con lector de
precio de los
No http://www.izettle.com
tarjetas para
productos de los
dispositivos móviles
clientes,
UI Atractiva y
Amigable, gráficos,
No está en español
Chicago, estadísticas, app No (14 días
Cashier Live No No $20/m
EUA
Desconocido
para iOS, integración
ni maneja peso
de prueba)
http://www.cashierlive.com
mexicano
de hardware, costos
accesibles
1 Manejo de pesos mexicanos // 2 Precio en Dólares Estadounidenses, "/m" significa por mes
Datos con base de consulta de 25 de junio de 2013
Figura C.4 Tabla de competencia de Sistemas punto de venta que operan con tecnologías Web.
P á g i n a | 168
1.3 Estrategia
El software propuesto utilizará tecnologías web que permitan una amplia y

rápida captación de clientes y ofreciendo una gran disponibilidad y compatibilidad
entre distintas plataformas. Además será distribuido como SaaS (Software como
Servicio) y manejará distintos planes que satisfagan las necesidades de cada cliente
de acuerdo con el volumen de sus ventas. Además de utilizar modelos de negocio
como el Freemium para aumentar la captación de nuevos clientes.
Las tecnologías propuestas se basan en aquellas que cuenten con licencias

de tipo libre o similar y con mayor documentación además de comunidades muy
activas. Dichas tecnologías deben ser dominadas por el equipo de trabajo para
lograr un desarrollo fluido que permita cumplir con los tiempos establecidos de
entrega.
La diferenciación de mercado estará basada inicialmente en sobrepasar las

desventajas de nuestros competidores, ofreciendo precios más accesibles y un
modelo freemium con capacidad limitada en funcionalidades y no en tiempo de uso,
no se manejará comisión por ventas, y desde sus inicios estará en español y con
cierto grado de especialización en el mercado mexicano sin crear dependencia de
esa estructura que en un futuro pueda obstaculizar la escalabilidad del sistema a el
mercado internacional.
CAPÍTULO II APLICACIONES WEB
CAPÍTULO II TECNOLOGÍAS PARA LA CONSTRUCCIÓN DE

APLICACIONES WEB + ANEXO A
CAPÍTULO VI MODELOS DE DISTRIBUCIÓN DE SOFTWARE
CAPÍTULO VII PUNTO DE VENTA

P á g i n a | 169
2 Análisis y Requerimientos Iterativos
El uso de una metodología de desarrollo de software ágil, se justifica por los

tiempos de entrega, el personal con el que se cuenta y la arquitectura flexible que
proporciona para soportar cambios a futuro.
La flexibilidad mencionada permite que para el desarrollo especifico de este

proyecto sean omitidas o sustituidas algunas de sus características de la
metodología pero siempre respetando los postulados del manifiesto ágil.
Un ejemplo de esto son las sesiones con el cliente, y hacer a este parte del
equipo, puesto que en este sistema no tenemos un cliente presencial, sino muchos
posibles clientes virtuales, este rol será llevado por alguno de los integrantes del
equipo, que en base a los conocimientos adquiridos en la investigación y el análisis
de la competencia, servirán para definir los requerimientos principales que formen
las historias de usuario. Este rol será rotativo, mientras que una persona cumple
con el rol de programador, el otro integrante cumplirá con el rol de cliente, y se
intercambiaran al terminar cada iteración o cuando se considere necesario.
A pesar de esta adaptación, gran parte de los aspectos estipulados en el

manifiesto ágil se respetan así como gran parte de la estructura propuesta por la
Programación Extrema.
CAPÍTULO VIII METODOLOGÍA DE DESARROLLO DE SOFTWARE ÁGIL

P á g i n a | 170
2.1 Historias de usuario (hasta la última iteración)
Figura C.5 Hoja 1 de las principales historias de usuario (hasta la última iteración).
P á g i n a | 171
Figura C.6 Hoja 2 de las principales historias de usuario (hasta la última iteración).
Las historias de usuario mostradas son las correspondientes a la última

iteración del sistema y contienen modificaciones en las cuales se agregaron o
eliminaron ciertos requerimientos, para cumplir el objetivo previsto para el sistema
hasta los alcances de la tesis.
P á g i n a | 172
3 Diseño Iterativo (Final)
Como se mencionó en el Capítulo XVIII la flexibilidad de la metodología

permite el uso de diagramas UML además de los artefactos propios de XP. Para
esta tesis, se utilizarán casos de uso generales (ver figura C.1), diagrama de
navegación (ver figura C.2) y diagrama E-R de la base de datos (ver figura C.3),
sólo con el objetivo de ayudar al lector y a futuros colaboradores a hacerse de una
imagen general sobre el funcionamiento del sistema.
4 Desarrollo Iterativo (Final) con Integración Continua
La integración continua es fundamental para el desarrollo de sistemas en

equipos de varios integrantes, no sólo en metodologías ágiles. La integración
continúa en el desarrollo de este sistema fue llevado a cabo mediante el controlador
de versiones GitHub y se encuentra disponible para su libre consulta en:
Figura C.7 Código QR que envía a la dirección de GitHub que contiene el código y otros archivos
del sistema
https://github.com/serchserch/wpv
P á g i n a | 173
Diagrama General de Clases
Figura C.8 Diagrama general de las principales clases del sistema

P á g i n a | 174
Diagrama Detallado de Navegación

P á g i n a | 175
Figura C.9 Diagrama detallado de navegación en el sistema.

P á g i n a | 176
Diagrama E-R
P á g i n a | 177
Figura C.10 Diagrama Entidad Relación de la Base de Datos.

P á g i n a | 178
5 Implementación
El sistema fue nombrado con las letras clave wpv (web punto de venta), y fue
montado en un servidor Apache y se instaló MySQL en el mismo equipo con las
siguientes características:
 Procesador: Intel Core i7

 RAM: 2 Memorias Kingston de 8Gb a 1033Mhz
 Disco Duro: Adata 80 Gb de Estado Sólido.
Se creó un servidor virtual para que la ruta wpv.com fuese la que mostrará
la aplicación. Modificando el archivo httpd.conf y descomentando la opción
#Include conf/extra/httpd-vhost.conf y agregando las siguientes líneas
al archivo vhost.conf ubicado en xampp\apache\conf\extra.
1 <VirtualHost *:80>
2 DocumentRoot "C:/xampp/htdocs/wpv/public_html/web"
3 ServerName wpv.com
4 ServerAlias wpv.com
5 <Directory "C:/xampp/htdocs/wpv/public_html/web" >
6 Options All
7 AllowOverride All
8 Order allow,deny
9 Allow from all
10 </Directory>
11 </VirtualHost>
Figura C.11 Configuración de Servidor Virtual en Apache.
P á g i n a | 179
La implementación del sistema se realizó con éxito de acuerdo a los alcances

contemplados en esta tesis:
 Utilizar tecnologías web.

 Permitir registro de clientes.
 Creación de sucursales y almacenes.
 Creación de impuestos.
 Registro de productos en almacén.
 Interfaz para venta de productos mediante un POS sin hardware.
 Aviso de Privacidad.
 Distribución diseñada para SaaS
Todas las imágenes usadas en esta tesis pueden ser consultadas en el

repositorio de github antes mencionado, incluyendo las capturas de pantalla del
sistema en producción.
En el repositorio podrán encontrarse las carpetas:

public_html el cual contiene todo el código del sistema.
src se encuentra la base de datos, dentro de la carpeta.
img están todas las imágenes utilizadas en el documento de la tesis.
screenshoots se encuentran las capturas de pantalla del sistema.
P á g i n a | 181
Anexo A
Tablas Comparativas de Tecnologías
Como puede observarse en las tablas comparativas no se contemplan criterios

relacionados con el rendimiento y velocidad de las tecnologías, puesto que estos dependen
de muchos factores que van desde el hardware hasta la plataforma en el que es ejecutada
e incluso puede afectar la configuración que se realice sobre la tecnología. Estos criterios
requieren un estudio mucho más exhaustivo, el cual no es contemplado de acuerdo a los
límites de esta investigación.
En algunas tecnologías como por ejemplo los ORMs sobre Symfony, las diferencias
de rendimiento son poco notables y en otras como los motores de plantillas sobre Symfony,
la velocidad es un criterio poco influyente puesto que su transformación (a código PHP) sólo
se realiza una vez y a partir de entonces se guarda en cache obteniendo un desempeño
muy similar de todos los motores de plantillas.
Tomando en cuenta los tiempos y objetivos de esta tesis, los criterios más
influyentes para la selección de las tecnologías fueron aquellas que ofrecieran un tiempo
menor de desarrollo, la mayoría de ellas seleccionadas de acuerdo a una curva de
aprendizaje relativamente baja del resto, de acuerdo con una autoevaluación de los
conocimientos de los participantes antes de comenzar con la tesis. Otro criterio influyente
es que contaran con una amplia documentación y grandes comunidades activas. Estos
criterios seleccionados, ofrecen mayor garantía de soporte y mayor tiempo de “vida” sobre
las tecnologías utilizadas, además de reducción de costos tanto en tiempo como en
recursos humanos.
Sin embargo, somos conscientes (los participantes de esta tesis) de que las
exigencias de un sistema como este pueden llegar a crecer, y no descartamos en ningún
momento la migración hacia otra tecnología que ofrezca un mejor rendimiento. Esto justifica
tanto la arquitectura como la metodología seleccionada, las cuales están diseñadas para
soportar dichos cambios a futuro.
NOTA: Como en el uso coloquial para describir la dificultad al aprender una

determinada herramienta de software, en el criterio de curva de aprendizaje Alto significa
mayor dificultad mientras Bajo representa menor dificultad de aprendizaje.
P á g i n a | 182
LENGUAJES DE PROGRAMACIÓN WEB MÁS POPULARES
Algunos sitios web que lo Mercado Curva de

Lenguaje Licencia Tipo Plataforma Paradigmas Año
usan3 Laboral4 aprendizaje 5
Estructurado, funcional,
MS orientado a objetos,
ASP.NET1 Propietaria Semicompilado
Windows concurrente, dirigido a
2002 bing.com, live.com, msn.com -- Media
eventos
Multi-
Go BSD Compilado
plataforma
Concurrente, imperativo 2009 google.com, soundcloud.com -- Media-Alta
GNU youtube.com, google.com,

Genérico, imperativo,
General Multi- twitter.com, facebook.com,
Java2 Public
Semicompilado
plataforma
orientado a objetos, 1995
amazon.com, ebay.com,
6% Baja
reflexivo, concurrente
License linkedin.com
Imperativo, orientado a facebook.com, google.com,

Multi-
PHP PHP License Interpretado
plataforma
objetos, procedural, 1995 yahoo.com, wikipedia.org, 21% Muy Baja
reflexivo wordpress.com
Python
Software Multi- Funcional, imperativo, facebook.com, google.com,
Python Foundation
Interpretado
plataforma orientado a objetos
1991
youtube.com, blogger.com
-- Baja
License
Multi- Funcional, imperativo, twitter.com, hulu.com,

Ruby BSD Semicompilado
plataforma orientado a objetos
1995
groupon.com
3% Media
1 Con Visual Basic.NET o C#. // 2 Java EE y/o JSP. // 3 En al menos uno de sus módulos o servicios. // 4 Según datos de craiglist.com, "--" significa menos del 1%. // 5 Basado
en una autoevaluación por parte de los desarrolladores de esta tesis de sus conocimientos al inicio del proyecto.
P á g i n a | 183
SERVIDORES WEB PHP

Curva de
Servidor Licencia Plataforma Año Algunos sitios web que lo usan2 Presencia3
aprendizaje 4
Apache License wikipedia.org, craiglist.org, ask.com,

Apache1 (Open-Source)
Multi-plataforma 1995
apple.com
64% Muy Baja
ramber.ru, wikipedia.org,
Nginx BSD Multi-plataforma 2002 tumblr.com, pinteres.com, 14.4% Media
wordpress.com
hotfile.com, youtube.com,
Lighttpd BSD Multi-plataforma 2003
thepiratebay.sx, meebo.com
0.4% Media-Alta
Linux, FreeBSD, lyrics.com, kaskus.us, zoznam.sk,

LiteSpeed Propietaria
Mac OSX, Solaris
2002
fanfiction.net
1.9% Media
1 Apache HTTP Server. // 2 En al menos uno de sus módulos o servicios. // 3 Según datos de w3techs.com, "--" significa menos del 0.1%. // 4 Basado en una
autoevaluación por parte de los desarrolladores de esta tesis de sus conocimientos al inicio del proyecto.
P á g i n a | 184
LENGUAJES DE PROGRAMACIÓN WEB EN EL CLIENTE

Tecnología Front- Algunos sitios web que lo Curva de
Licencia Plataforma Año Presencia3
End usan1 aprendizaje 4
Multi-plataforma
Dart BSD (Compilado a 2011 DN -- Media
JavaScript)
Flash Freeware (Adobe Flash adobe.com, bbc.co.uk,

(plugin) 1998 17.9% Media
(ActionScript) Player) yahoo.com, flickr.com
GNU General Public (Máquina Virtual de

Java (applet) License (Java) Java)
1995 DN 0.1% Media-Alta
facebook.com, google.com.
Multi-plataforma
JavaScript BSD (ECMAScript)
(Navegador)
1995 Youtube.com, amazon.com, 89.2% Muy Baja
live.com, wikipedia.com
Siverlight freeware (Svierlight msn.com, xbox.com,

(plugin) 2007 0.2% Media-Alta
(.NET) 'Player') screencast.com, netflix.com
VisualBasic -- Internet Explorer 1996 DN -- Media

Script
1 En al menos uno de sus módulos o servicios. "DN" Significa "Dato No disponible" // 3 Según datos de w3techs.com, "--" significa menos del 0.1%. // 4 Basado en una
autoevaluación por parte de los desarrolladores de esta tesis de sus conocimientos al inicio del proyecto.
P á g i n a | 185
BASES DE DATOS MÁS UTILIZADAS

Algunos sitios web Numero de Curva de
SGBD Tipo Licencia Plataforma Año
que lo usan1 Popularidad2 aprendizaje 3
GNU (Public
MariaDB Relacional
License)
Multi-plataforma 2009 wikipedia.org 6 Media-baja
Microsoft live.com, msn.com,

Relacional Propietario MS Windows 1989 2 Media
SQL Server bing.com
foursquare.com, bit.ly,
MongoDB NoSQL GNU APGL Multi-plataforma 2009 sourceforce.net, 5 Media
shutterfly.com
facebook.com,
youtube.com,
GNU (Public
MySQL Relacional
License)
Multi-plataforma 1995 yahoo.com, 1 Muy Baja
wikepedia.org,
wordpress.com
Oracle
Relacional Propietario Multi-plataforma 1978 ebay.com 4 Media
Database
whitepages.com,
PostfreSQL License etsy.com,
PostgreSQL Relacional
(Open Source)
Multi-plataforma 1995
calorieKing.com,
3 Media
chicagocrime.org
1 En al menos uno de sus módulos o servicios. // 2 Según datos de las búsquedas realizadas en google.com obtenidos de google.trends.com (junio 2013) // 3 Basado
en una autoevaluación por parte de los desarrolladores de esta tesis de sus conocimientos al inicio del proyecto.
P á g i n a | 186
FRAMEWORKS PHP MÁS UTILIZADOS
Número de Curva de
FRAMEWORK Licencia Plataforma Año
Popularidad2 aprendizaje 3
CakePHP MIT Multi-plataforma 2005 1 Media
Codeigniter Open Software License Multi-plataforma 2006 2 Media
Symfony MIT Multi-plataforma 2005 3 Muy Baja
Yii New BSD Multi-plataforma 2008 5 Media
Zend New BSD Multi-plataforma 2006 4 Media
1 En al menos uno de sus módulos o servicios. // 2 Según datos de las búsquedas realizadas en google.com obtenidos de google.trends.com (junio
2013) // 3 Basado en una autoevaluación por parte de los desarrolladores de esta tesis de sus conocimientos al inicio del proyecto.
P á g i n a | 187
LIBRERÍAS JAVASCRIPT MÁS UTILIZADAS

Curva de
Librería Licencia Plataforma Año Algunos sitios web que lo usan1 Presencia2
aprendizaje 3
Microsoft Public systweak.com, monster.com,

ASP.NET Ajax License
Multi-navegador 2005
agoda.com, united.com, legacy.com
2.4% Media
amazon.com, ask.com, msn.com,

jQuery MIT Multi-navegador 2006
tumblr.com, microsoft.com, craiglist.org
54.8% Muy Baja
microsoft.com, babylon.com, adf.ly,

Modernizr MIT y BSD Multi-navegador 2009
about.com, webly.com
3.2% Media
verizon.com, joomla.org, pogo.com,

MooTools MIT Multi-navegador 2006
aeriagames.com
5.2% Media
apple.com, nocovideo.jp, nba.com,

Prototype MIT Multi-navegador 2008
youku.com, lastimes.com
2.9% Media
1 En al menos uno de sus módulos o servicios. // 2 Según datos de w3techs.com (junio 2013) // 3 Basado en una autoevaluación por parte de los
desarrolladores de esta tesis de sus conocimientos al inicio del proyecto.
P á g i n a | 188
ORM SOBRE SYMFONY
Curva de
ORM Licencia Plataforma Año En Symnofy 2 Comunidad
aprendizaje 1
Doctrine MIT Multi-Plataforma 2008 Por defecto Muy Activa Muy Baja
Propel MIT Multi-Plataforma 2003 Plugin extra Poco Activa Baja
1 Basado en una autoevaluación por parte de los desarrolladores de esta tesis de sus conocimientos al inicio del proyecto.
MOTOR DE PLANTILLAS SOBRE SYMFONY
Curva de
ORM Licencia Lenguaje Año En Symnofy 2 Comunidad
aprendizaje 1
PHP, Ruby, Go,

Mustache MIT
JavaScript, .NET
2009 Plugin extra Muy Activa Baja
Smarty LGPL PHP 2001* Plugin extra Muy Activa Baja
Twig BSD PHP 2008 Por Defecto Muy Activa Muy Baja
1 Basado en una autoevaluación por parte de los desarrolladores de esta tesis de sus conocimientos al inicio del proyecto. * Año
Aproximado de acuerdo al copyright de su versión 1.0
P á g i n a | 189
Anexo B
Aviso de privacidad.
En términos de lo previsto en la Ley Federal de Protección de Datos Personales en

Posesión de los particulares, denominada “la Ley” en lo sucesivo, EMPRESA S.A, con
dirección en Calle Ayuntamiento No 20, Local H, Colonia Atizapán Centro, Atizapán estado
de México, establece el presente aviso de Privacidad conforme a lo siguiente:
El presente documento tiene finalidad la protección de los datos personales de los

sujetos registrados en el sistema WPV.COM en lo sucesivo llamados USUARIO, y
establecer que los datos mediante su tratamiento legítimo controlado por la EMPRESA S.A.,
garantizará los derechos del USUARIO de acuerdo a la Ley.
La EMPRESA S.A. recopilará información necesaria para su correcta operación y el

alcance de sus fines. Los datos personales solicitados al USUARIO son los siguientes:
 Nombre y Apellidos.
 Genero.
 Dirección.
 Dirección de correo electrónico.
 Teléfono Local y móvil.
 Nombre de su Empresa o Razón Social
Además de solicitar información que detalle el giro del negocio del USUARIO. La
EMPRESA S.A. pude llegar a solicitar información sensible como Números de Tarjetas de
Crédito, y Contraseñas para la manipulación del sistema, datos que serán tratados
mediante técnicas de encriptación que ofrezcan mayor seguridad al USUARIO.
Así mismo la EMPRESA S.A. puede utilizar la información correspondiente del flujo
de las operaciones realizadas por el USUARIO, como ventas y compras, así como la
información involucrada en la operación que detallen al servicio, al producto, los metadatos,
lugar y fecha de dichas operaciones.
El USUARIO al proporcionar los datos personales a la EMPRESA S.A. acepta y

autoriza que los datos formarán parte de nuestra base de datos y que serán tratados bajo
alguna o algunas de las siguientes finalidades:
P á g i n a | 190
 Realizar estudios sobre datos demográficos, intereses y comportamiento; estudios

de mercado y de consumo a efecto de adquirir y ofrecer productos y servicios
personalizados, así como publicidad y contenidos más adecuados a las
necesidades del USUARIO.
 Con el objeto de poder entregar productos, servicios y soluciones, la EMPRESA
S.A. y sus encargados han celebrado o celebrarán diversos acuerdos comerciales
con diversos proveedores tanto en territorio nacional como en el extranjero, para
que le suministren los productos y servicios ofrecidos por el EMPRESA S.A., en el
entendido de que dichos proveedores están obligados, a mantener la
confidencialidad de los datos personales suministrados y a observar el Aviso de
Privacidad.
En ningún momento y bajo ninguna circunstancia EMPRESA S.A. podrá divulgar,

revelar o de cualquier otra manera hacer conocimiento de cualquier tercero, con el cual no
se halla celebrado algún acuerdo, de la información confidencial que provee el USUARIO
a menos que por Ley, se marque lo contrario.
El USUARIO puede exigir en cualquier momento el cumplimiento de sus derechos

ARCO de acuerdo a lo estipulado en la Ley y bajo las restricciones mencionadas en la
misma. Dirigiéndose a las instalaciones de EMPRESA S.A ubicadas en la dirección
mencionada al principio de este documento o a los siguientes medios:
 Teléfono: +52 55 1111-1111

 Correo electrónico: [email protected]
El área interna de la EMPRESA S.A. responsable del tratamiento de los datos

personales de USUARIO, está obligada a cumplir con los principios de licitud,
consentimiento, información, finalidad, y responsabilidad tutelados en la Ley, por tal motivo
EMPRESA S.A. se compromete a mantener las medidas de seguridad tanto
administrativas como físicas que permitan protegerlos contra cualquier daño, alteración o
acceso no autorizado.
La empresa EMPRESA S.A se reserva el derecho de actualizar periódicamente el

Aviso en cuyos casos el USUARIO registrado será notificado y al mismo tiempo el
USUARIO debe asumir su responsabilidad de revisar el contenido del Aviso
periódicamente.
P á g i n a | 191
Anexo C
Manifiesto por el Desarrollo Ágil de Software
Estamos descubriendo formas mejores de desarrollar software tanto por nuestra

propia experiencia como ayudando a terceros. A través de este trabajo hemos aprendido
a valorar:
 Individuos e interacciones sobre procesos y herramientas

 Software funcionando sobre documentación extensiva
 Colaboración con el cliente sobre negociación contractual
 Respuesta ante el cambio sobre seguir un plan
Esto es, aunque valoramos los elementos de la derecha, valoramos más los de la
izquierda.
Kent Beck James Grenning Robert C. Martin

Mike Beedle Jim Highsmith Steve Mellor
Arie van Bennekum Andrew Hunt Ken Schwaber
Alistair Cockburn Ron Jeffries Jeff Sutherland
Ward Cunningham Jon Kern Dave Thomas
Martin Fowler Brian Marick
Seguimos estos principios:
1. Nuestra mayor prioridad es satisfacer 3. Entregamos software funcional

al cliente mediante la entrega frecuentemente, entre dos semanas y
temprana y continua de software con dos meses, con preferencia al
valor. periodo de tiempo más corto posible.
2. Aceptamos que los requisitos 4. Los responsables de negocio y los

cambien, incluso en etapas tardías desarrolladores trabajamos juntos de
del desarrollo. Los procesos Ágiles forma cotidiana durante todo el
aprovechan el cambio para proyecto.
proporcionar ventaja competitiva al
cliente.
5. Los proyectos se desarrollan en torno
a individuos motivados. Hay que
P á g i n a | 192
darles el entorno y el apoyo que

necesitan, y confiarles la ejecución
9. La atención continua a la excelencia
del trabajo.
técnica y al buen diseño mejora la
Agilidad.
6. El método más eficiente y efectivo de
comunicar información al equipo de
10. La simplicidad, o el arte de maximizar
desarrollo y entre sus miembros es la
la cantidad de trabajo no realizado,
conversación cara a cara.
es esencial.
7. El software funcionando es la medida

11. Las mejores arquitecturas, requisitos
principal de progreso.
y diseños emergen de equipos auto-
organizados.
8. Los procesos Ágiles promueven el
desarrollo sostenible. Los
12. A intervalos regulares el equipo
promotores, desarrolladores y
reflexiona sobre cómo ser más
usuarios debemos ser capaces de
efectivo para a continuación ajustar y
mantener un ritmo constante de
perfeccionar su comportamiento en
forma indefinida.
consecuencia.
Anexo D
Manual de usuario
El manual de usuario se encuentra disponible para su libre consulta en la siguiente

liga, el manual sólo representa la versión entregada en la última iteración correspondiente
a los alcances de esta tesis
https://github.com/serchserch/wpv/blob/master/src/Anexo%20D%20Manual%20de%20Usuario.d
ocx
P á g i n a | 193
Proyecciones a Futuro
El sistema punto de venta es sólo un módulo que conformará la plataforma

comercial que se tiene prevista, la cual permitirá a nuestros clientes tener una tienda
electrónica para vender en línea, contar con POS para vender en sitio y contar con
un CRM para mejorar los lazos con sus clientes.
La plataforma proporcionará a nuestros clientes las herramientas necesarias

para la administración y control de operaciones relacionadas con la compra, venta
y registro de productos y/o servicios.
La misma plataforma ofrecerá herramientas para que los clientes de nuestros

clientes puedan llevar registros de sus compras, tiendas favoritas, realizar
búsquedas de productos por tipo, precio, localización, etc. Todo lo anterior con la
finalidad de ser una aplicación atractiva para dichos usuarios e incrementar el
registro de los mismos ofreciendo así un gran mercado potencial al cual pueden
llegar nuestros clientes y creando un circulo virtuoso en torno a ese modelo.
La apertura de nuestro sistema permitirá a desarrolladores externos crear

módulos especializados para satisfacer necesidades aún más específicas que
serán vendidos en nuestra propia tienda de aplicaciones.
Como pude observarse el POS representa sólo una de las tres piezas
principales que conformaran la gran plataforma enfocada a negocios dedicados al
comercio (principalmente minoristas), y que permitirá a nuestros clientes realizar
sus operaciones más comunes de manera fácil y rápida incluyendo todas las
ventajas de las aplicaciones basadas en tecnologías web.
P á g i n a | 194
CONCLUSIONES
En la presente tesis se realizó un análisis e investigación para comprobar que

los sistemas de punto de venta como aplicación web, pueden facilitar a las micro y
pequeñas empresas del sector comercial a mejorar la administración y optimización
de sus recursos.
En dicha investigación de la economía mexicana, podremos observar que el

99.87% está integrada por micro y pequeñas empresas y que en México
actualmente las MiPYME generan el 52 % del PIB y el 72 % de empleo en México
esto según Censo Económico de INEGI realizado en 2009. 1 Y más de la mitad
pertenece al sector de venta al por menor. Ante este escenario, creamos una
aplicación punto de venta POS (del inglés Point of Sale) como aplicación web.
El uso de las tecnologías web para el desarrollo de aplicaciones permiten que

la información y la lógica responsable del funcionamiento del sistema sean
almacenados y ejecutados en un lugar remoto, lo cual permite a los clientes ejecutar
la aplicación a través de un navegador web y no crear dependencia del sistema
operativo. Este tipo de sistemas permiten ofrecer a los clientes un mejor servicio de
mantenimiento y actualización, ya que el sistema no está instalado en sus equipos
si no en nuestros servidores; así que podrán confiar que si sus equipos tuvieran
algún inconveniente tendrían respaldada su información remotamente.
__________________________________________________________________
1 PyMES, eslabón fundamental para el crecimiento en México. (s.f.). Recuperado el 22 de mayo de

2013 de http://www.promexico.gob.mx/negocios-internacionales/pymes-eslabon-
fundamental-para-el-crecimiento-en-mexico.html.
P á g i n a | 195
Por otra parte, las tecnologías libres juegan un papel importante en el

desarrollo de esta investigación ya que nos ha permitido explorar y explotar al
máximo los recursos que nos ofrecen para el desarrollo de esta aplicación,
determinamos que los lenguajes que soportaran el sistema son PHP y JavaScript.
Los modelos y funcionalidades provistos por las librerías y principalmente el

framework utilizado, nos proporcionaron una estructura detallada y modular que
facilitará el mantenimiento, agregación y/o eliminación de módulos.
No obstante, los puntos mencionados anteriormente no serán justificados sin

tener en cuenta la seguridad, algo muy importante porque el sistema generar
información y esta tiene que estar protegida desde la parte informática hasta el lado
legal.
Ahora bien la información generada por el punto de venta estará protegida

legalmente bajo la normatividad de la Ley Federal de Protección de Datos
Personales en Posesión de los Particulares la cual garantizara la protección de los
datos proporcionados en el POS; así los usuarios de la aplicación sabrán y tendrán
en cuenta que si no cumplimos o acatamos la ley está misma los amparara y los
responsables del mal uso de los datos se harán acreedores a las sanciones
establecidas.
A continuación, nos gustaría mencionar algunos puntos clave para la

conclusión de este trabajo:
 Hasta ahora, hemos demostrado que la automatización de la

información es de gran ayuda en el entorno comercial.
P á g i n a | 196
 Un sistema punto de venta como aplicación web ayudara a las

MyPIME tener una mejor administración y control de sus procesos.
 Al implementar este tipo de sistemas en las micro y pequeñas
empresas se incrementaran las ganancias, tendrán escalabilidad,
simplificara y reducirá los tiempos de espera.
 Existirá un crecimiento económico y satisfacera las necesidades de
los usuarios siempre y cuando cubra sus necesidades.
Al seguir una metodología ágil permitió que su diseño fuese concebido para
proveer de una gran flexibilidad del sistema y permitir su escalabilidad a futuro de
una forma menos complicada. Es importante mencionar que la metodología es tan
flexible que no existe una guía establecida que mencione exactamente cuáles son
los pasos a seguir, puesto que su naturaleza es esa, la flexibilidad, lo cual permite
tanto a los desarrolladores como los analistas experimentar con métodos, fusionar
metodologías e intercambiar funciones para adaptarlos al sistema desarrollado.
Lo anterior nos permitió diseñar y desarrollar la aplicación basándonos en el

análisis realizado a los requerimientos y especificaciones de ARTS, así como la
información, los métodos y técnicas de nuestra competencia.
El sistema desde un inicio fue diseñado para su futura comercialización es

por eso que se planteó un modelo de distribución basado en servicios. La
distribución de Software as a Service permite que el cliente sólo pague por el tiempo
que usa el sistema sin depender de una plataforma de software o hardware
específica, lo cual le permite reducir sus costos de adquisición inicial a comparación
de un POS tradicional. Dicho modelo de distribución y la arquitectura también se
justifica por los actuales avances tecnológicos y el aumento de una sociedad más
adaptada a las Tecnologías de la Información (TI) y principalmente el uso intensivo
de los servicios basados en la Web.
P á g i n a | 197
Es importante mencionar que tanto la información contenida en esta tesis como el

código almacenado en GitHub, sólo representan las bases para el producto
comercial que se pretende realizar del sistema. La estructura de la base de datos, la
estructura de las clases, los algoritmos de encriptación y autenticación así como la
interfaz gráfica serán cambiados para evitar vulneraciones y de esta forma poder
ofrecer un servicio con mayor nivel de seguridad y mejorar la experiencia de usuario
para nuestros futuros clientes.
¡GRACIAS!
.
“Si quieres llegar rápido, camina solo.

Si quieres llegar lejos, camina en grupo”
.
P á g i n a | 198
Bibliografía
Documentos no periódicos
Accid. (2010). Nuevas Tendencias en Management: Fundamentos y Aplicaciones.

Madrid, España: Bresca.
A. Meyer Eric. (2009). CSS: The Definitive Guide [CSS: La guía definitiva]. (3a ed.).
Estados Unidos de América: O’Reilly Media Inc.
Beck K., et al. (2004). Extreme Programming Explained: Embrace Change

[Programación extrema explicada: aceptación del cambio]. (2da ed.). Estados
Unidos de América: Addison-Wesley.
Caivano R., Villoria L. (2009). Aplicaciones Web 2.0 para aplicaciones educativas
en la U.N.V.M. Cordoba, República Argentina: Eduvim.
Coronel, Morris, Rob. (2013). Database Systems: Design, Implementation, and

Management, Course Technology [Bases de Datos: Diseño, Implementación
y Gestión, Curso de Tecnología]. Estados Unidos de América: Cengage
Learning.
Cross M. (2007). Developer's Guide to Web Application Security [Guía de

desarrolladores para aplicaciones web seguras]. Estados Unidos de América:
Syngress.
Doyle M. (2009). Beginning PHP 5.3. [Comenzando con PHP 5.3.]. Estados Unidos
de América: Wrox.
Fowler M., Scott K. (1999). UML gota a gota (Jaime González V., David Morales
Peake trad.). Estados Unidos Mexicanos: Pearson.
Gómez Vieites A. (2007). Enciclopedia de la Seguridad Informática. México:

Alfaomega
González Gómez J. (2002). Control y gestión del área comercial y de producción de

la PYME: Una aplicación práctica con SP Factura Plus y SP TPV plus Élite
2003. Coruña, España: Netbiblo.
Harrison G. (2006). MySQL Stored Procedure Programming [MySQL Programación

de procedimientos almacenados]. Estados Unidos: O'Reilly Media.
Hernández Sampieri R. et al. (1991). Metodología de la Investigación. Edo. de

México, Estados Unidos Mexicanos: MCGRAW-HILL.
P á g i n a | 199
Instituto Nacional de Estadística y Geografía. (2009). Micro, pequeña, mediana y

gran empresa Estratificación de los establecimientos, Censos Económicos
2009. Aguascalientes, Estados Unidos Mexicanos: [s.n].
Kane R. (2009). Software Escrow for Dummies [´Fideicomiso´ de Software para

Tontitos]. Estados Unidos de América: Iron Mountain Digital.
Kruchten P. (1995). Architectural Blueprints—The “4+1” View Model of Software

Architecture [Planos Arquitectonicos: El “4+1” de la Arquitectura de Software
Modelo Vista]. En IEEE Software (pp. 42-50). (Vol. 12). Estados Unidos de
América: [s.n].
López Quijado J. (2007). Domine Php y Mysql. (2a ed.). Barcelona, España: Ra-Ma.
Luján Mora S. (2001). Programación en Internet: clientes web. España: Club

Universitario.
M. Leiner B., et al. (2009). A Brief History of the Internet [Una Breve Historia Del
Internet]. Nueva York, Estados Unidos de América: ACM.
MacIntyre P. et al. (2011). Pro PHP Programming [Programando profesionalmente

con PHP]. Estados Unidos de América: Apress.
Molina Caballero J. (2007). Implantación de Aplicaciones Informáticas de Gestión.

España: Visión Net.
Monge. G. R., Alfaro. A. C., Alfaro C. J. (2005). TICs en las PYMES de

Centroamérica, Impacto de la adopción de las tecnologías de la información
y la comunicación en el desempeño de las empresas. Costa Rica: Editorial
Tecnológica de Costa Rica.
National Retail Federation. (2013). Unified POS [Punto de Venta Unificado]. Estados
Unidos de América: [s.n].
Pavón Puertas J. (2006). Creación de un Portal con Php y MySQL. (2a ed.). Estados
Unidos Mexicanos: Ra-Ma.
Porebski B., Karol P. (2011). Building PHP Applications with Symfony, CakePHP,
and Zend Framework [Construyendo una aplicación PHP con Symfony,
CakePHP y Zend Framework]. Indiana, Estados Unidos de América: Wiley
Publishing, Inc.
Quero Catalinas Enrique. (2001). Sistemas operativos y lenguajes de programación.

Madrid. España: Ediciones Paraninfo.
Shema M. (2012). Hacking Web Apps: Detecting and Preventing Web Application
Security Problems [Hacking de Aplicaciones Web: Detección y Prevención de
P á g i n a | 200
Problemas de Seguridad de las Aplicaciones Web]. Estados Unidos de

América: Syngress.
Software & Information Industry Association. (2001). Software as a Service:

Strategic Backgrounder [Software como Servicio: Antecedentes
Estratégicos]. Washington DC, Estados Unidos de América: [s.n].
Sommerville I. (2005). Ingeniería del Software (María Isabel Alfonso Galipienso

trad.). (7a ed.). Madrid, España: Pearson.
Publicaciones Gubernamentales
Estados Unidos Mexicanos. Congreso General. Ley Federal de Protección de Datos

Personales en Posesión de los Particulares. DOF 05-07-2010. Diario Oficial
de la Federación. 05 de julio de 2010.
Páginas Web
A Brief History of SaaS [Una breve historia sobre el Software como Servicio]. (s.f.).
http://www.computerworld.com/pdfs/Service-Now-BriefhistoryofSaaS.pdf.
April 2013 Web Server Survey [Encuesta de Servidores Web de Abril de 2013]. (02
de abril de 2013). Recuperado el 29 de abril de 2013 de
http://news.netcraft.com/archives/2013/04/02/april-2013-web-server-
survey.html.
Application Vulnerability Trends Report: 2013 [Informe de las Tendencias en

Vulnerabilidad de las Aplicaciones: 2013]. (2013). Recuperado el 05 de junio
de 2013 de http://info.cenzic.com/rs/cenzic/images/Cenzic-Application-
Vulnerability-Trends-Report-2013.pdf.
Cascading Style Sheets [Hojas de Estilo en Cascada]. (s.f.). Recuperado el 23 de

abril de 2013 de http://www.w3.org/Style/CSS/.
Continuous Integration [Integración continúa]. (01 de mayo de 2006). Recuperado

el 25 de junio de 2013 de
http://martinfowler.com/articles/continuousIntegration.html.
P á g i n a | 201
Declaración Universal de Los Derechos Humanos. (s.f.). Recuperado el 11 de junio

de 2013 de http://www.un.org/es/documents/udhr/index_print.shtml.
Estudio 2012 de hábitos y percepciones de los mexicanos sobre Internet y diversas

tecnologías asociadas. (2012). Recuperado el 25 de junio de 2013 de
http://www.wip.mx/estudios_wip.html.
Gartner Says Worldwide Software-as-a-Service Revenue to Reach $14.5 Billion in

2012 [Gartner dice que los ingresos del Software como Servicio a nivel
mundial pueden llegar a $14,5 mil millones en 2012]. (27 de marzo de 2012).
http://www.gartner.com/newsroom/id/1963815.
Hábitos de los Usuarios de Internet en México 2013. (2013). Recuperado el 25 de

junio de 2013 de
http://www.amipci.org.mx/?P=editomultimediafile&Multimedia=348&Type=1.
HTML 4.01 Specification [Especificación HTML 4.01]. (24 de diciembre de 1999).

Recuperado el 20 de abril de 2013 de http://www.w3.org/TR/1999/REC-
html401-19991224/.
HTML Standard by Ian Hickson (Google) [El Estándar HTML por Ian Hickson de
Google]. (s.f.). Recuperado el 06 de junio de 2013
http://www.whatwg.org/specs/web-apps/current-work/#is-this-html5?.
IBM solidDB 6.3 and IBM solidDB Universal Cache 6.3 Information Center. (s.f.).
http://publib.boulder.ibm.com/infocenter/soliddb/v6r3/index.jsp?topic=/com.i
bm.swg.im.soliddb.sql.doc/doc/tables.rows.and.columns.html.
Improving Web Application Security: Threats and Countermeasures [Mejorando la

seguridad de las Aplicaciones Web: Amenazas y Contramedidas]. (s.f.).
Recuperado el 05 de junio de 2013 de http://msdn.microsoft.com/en-
us/library/ms994921.aspx.
Instituto Federal de Acceso a la información y Protección de Datos Misión Visión y

Objetivos. (s.f.). Recuperado el 10 de Junio de 2013 de
http://inicio.ifai.org.mx/_catalogs/masterpage/misionViosionObjetivos.aspx.
Internet Usage Statistics, Population and Telecom Reports for the Americas. (30 de
junio de 2012). Recuperado el 25 de junio de 2013 de
http://www.internetworldstats.com/stats2.htm.
jQuery Usage Statistics [Estadisticas de Uso de jQuery]. (s.f.). Recuperado el 29 de

abril de 2013 de http://trends.builtwith.com/javascript/JQuery.
JSON Tutorial. (s.f.). Recuperado el 12 de junio de 2013 de

http://www.w3schools.com/json/.
P á g i n a | 202
Metodologías ágiles. (s.f.). Recuperado el 23 de junio de 2013 de

http://www.javiergarzas.com/metodologias-agiles.
Modelo de almacenamiento encriptado. (s.f.). Recuperado el 14 de junio de 2013 de

http://php.net/manual/es/security.database.storage.php.
My Favorite Business Model [Mi Modelo de Negocios Favorito]. (23 de marzo de

2006). Recuperado el 19 de junio de 2013 de
http://avc.blogs.com/a_vc/2006/03/my_favorite_bus.html.
National Retail Federation [Federación Nacional de Minoristas]. (s.f.). Recuperado

el 11 de junio de 2013 de http://www.nrf-arts.org/.
PHP: Hypertext Preprocessor. (s.f.). Recuperado el 20 de abril de 2013 de

http://www.php.net.
PHP just grows & grows [PHP sólo crece y crece]. (31 de enero de 2013).
Recuperado el 04 de mayo de 2013 de
http://news.netcraft.com/archives/2013/01/31/php-just-grows-grows.html.
PHP MySQL Introduction [Introducción a PHP MySQL]. (s.f.). Recuperado el 26 de

abril de 2013 de http://www.w3schools.com/php/php_mysql_intro.asp.
PyMES, eslabón fundamental para el crecimiento en México. (s.f.). Recuperado el

22 de mayo de 2013 de http://www.promexico.gob.mx/negocios-
internacionales/pymes-eslabon-fundamental-para-el-crecimiento-en-
mexico.html.
RFC 1180 A TCP/IP Tutorial [RFC 1180 Un Tutorial TCP/IP]. (Junio de 1991).
Recuperado el 25 de marzo de 2013 de
http://tools.ietf.org/html/rfc1180#page-12.
RFC 2616 - Hypertext Transfer Protocol. (Junio de 1999). Recuperado el 20 de

marzo de 2013 de http://tools.ietf.org/html/rfc2616.
Software as a Service [Software como Servicio]. (s.f.). Recuperado el 20 de junio de

2013 de http://cloudtaxonomy.opencrowd.com/taxonomy/software-as-a-
service/.
Team spirit agility counts [Espíritu de Equipo, la agilidad cuenta]. (20 de septiembre
de 2001). Recuperado el 23 de junio de 2013 de
http://www.economist.com/node/779429.
The WorldWideWeb browser [El Navegador WorldWideWeb]. (s.f.). Recuperado el

03 de junio de 2013 de http://www.w3.org/People/Berners-
Lee/WorldWideWeb.html.
P á g i n a | 203
Usuarios de las tecnologías de información 2001 a 2012. (29 de noviembre de

http://www3.inegi.org.mx/sistemas/sisept/default.aspx?t=tinf204&s=est&c=1
9437.
W3Counter Global Web Status [W3Counter Estatus Global de la Web]. (Junio de

http://www.w3counter.com/globalstats.php?year=2013&month=04.
Web 2.0: Compact Definition? [La Web 2.0 ¿En una definición compacta?]. (01 de
octubre de 2005). Recuperado el 21 de junio de 2013 de
http://radar.oreilly.com/2005/10/web-20-compact-definition.html.
What is a POS System? [¿Qué es un Sistema Terminal Punto de Venta?]. (s.f.).

Recuperado el 11 de junio de 2013 de http://www.wisegeek.org/what-is-a-
pos-system.htm#didyouknowout.
What is Symfony2? By Fabien Potencier [¿Qué es Symfony2? Por Fabien

Potencier]. (25 de Octubre de 2011). Recuperado el 13 de junio de 2013 de
http://fabien.potencier.org/article/49/what-is-symfony2.

Tesis Desarrollo de Un Punto de Venta

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Tesis Desarrollo de Un Punto de Venta

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD NACIONAL AUTÓNOMA DE MÉXICO

FACULTAD DE ESTUDIOS SUPERIORES CUAUTITLÁN

DESARROLLO DE UN PUNTO DE VENTA COMO APLICACIÓN WEB

CUAUTITLÁN IZCALLI, ESTADO DE MÉXICO 2014

El uso de imágenes, fragmentos de videos, y demás material que sea

Figura 1.1 Imagen que ilustra la clasificación de MiPyMEs de acuerdo a la

Figura 1.2 Gráfico que muestra los sectores de la economía

Figura 2.1 Arquitectura de 3 capas o niveles de una Aplicación Web……………….17

Figura 2.2 Patrón de Arquitectura Hibrido utilizado en el desarrollo de esta

Figura 3.2 Gráfico de Netcraft que muestra el crecimiento a nivel mundial de la

Figura 3.5 Ejemplo de persistencia de un objeto DQL con Doctrine 2………………58

Figura 3.6 Ejemplo de plantilla HTML usando PHP ‘puro’.………………...…………60

Figura 3.7 Ejemplo de plantilla HTML usando el motor de plantillas Twig….………61

Figura 3.8 Ejemplo de JSON……………………………………………………………62

Figura 4.3 Escapado de caracteres con htmlspecialchars de PHP……………....…69

Figura 4.6 Ejemplo de consulta a base de datos sin protección de escapado de

Figura 4.7 Ejemplo de Inyección SQL en el campo de un formulario………………..73

Figura 4.12 Ejemplo de encriptación de una contraseña utilizando Symfony………76

Figura 4.13 Ejemplo de configuración del archivo YAML access_control para

Figura 5.2 Logotipo del Instituto Federal de Acceso a la Información y Protección de

Figura 6.1 Modelos del Cómputo en la Nube………………………………...………112

Figura 6.4 Grafico representativo del modelo ASP y SaaS……………….………..121

Figura 8.1 Diagramas representativos de las metodologías tradicional en cascada y

Figura 8.2 Diagramas representativos de las metodologías tradicional RUP y

Figura 8.4 Gráfico de la estructura de Programación Extrema (XP) con tiempos

Figura 8.5 Gráfico representativo del ciclo de vida de la Programación Extrema

Figura 8.6 Gráfico representativo del funcionamiento de SVC en la nube………154

Figura 8.7 Formato de artefacto Historia de usuario para XP………………………157

Figura 8.8 Formato de artefacto Caso de Aceptación de Pruebas para XP…...….156

Figura 8.9 Formato de artefacto Tarea de Ingeniería para XP……………………..159

Figura C.5 Hoja 1 de las principales historias de usuario (hasta la última

Figura C.6 Hoja 2 de las principales historias de usuario (hasta la última

Figura C.8 Diagrama general de las principales clases del sistema……………….173

Figura C.9 Diagrama detallado de navegación en el sistema………………………175

Figura C.10 Diagrama Entidad Relación de la Base de Datos. ……………………177

Figura C.11 Configuración de Servidor Virtual en Apache………………………….178

Con el uso de los sistemas de cómputo para la automatización de procesos

El uso de las TIC (Tecnologías de la Información y la Comunicación) puede

“En el campo económico, la caída de las barreras al comercio, la reducción

En México actualmente hay más de 4 millones unidades empresariales

Las empresas dedicadas al comercio al por menor, tienen necesidades muy

La tendencia actual y la infraestructura con la que se cuenta hoy en día

El desarrollo de un POS creado como Aplicación Web conlleva muchas

Siguiendo el esquema de distribución de Software como Servicio para

“cada vez más organizaciones están dejando de comprar licencias de

El uso de tecnologías libres permite que el costo de desarrollo y

Con los avances tecnológicos actuales y un aumento de la sociedad adaptada a

La pequeña y mediana empresa proporciona más de la mitad de todos los

Una empresa la podemos definir como la entidad integrada por capital

Las características generales de una empresa se enlistan a continuación:

1. Recursos humanos, de capital, técnicos y financieros.

Es el término utilizado para referirse a las micro, pequeña y mediana empresa,

De las cuales 4 millones 743 unidades empresariales son micro y pequeña

Las MiPYME generan el 52 % del PIB y el 72 % de empleo en México esto

Normalmente para la clasificación de las empresas por su tamaño se toman

Para México las PYMES, son parte fundamental de la economía e

La Secretaría de Economía (SE) y la Secretaría de Hacienda y Crédito Público

“Las empresas micro, pequeñas y medianas representan a nivel mundial el

Podemos mencionar algunas de las ventajas de las Pymes:

 Las PYMES son el principal motor dentro de la economía de México.

1.4 Sector Comercial

Según el números obtenidos del Censo Económico de 2009 de comercios en el

SECTORES ECONÓMICOS EN MÉXICO