Flavors of the States ‘Saborea los estados’ Proyecto web para la gestión y venta de productos alimenticios americanos

(1)

Universidad de Valladolid

E. U. de Informática (Segovia)

Ingeniería Técnica en Informática de Gestión

Flavors of the States

“Proyecto web para la gestión y venta de

productos alimenticios americanos”

(2)

(3)

A mi hermano y a mis padres por su apoyo, y muy en especial a mi prometida

Cassidy sin la cuál, habría sido imposible sacar este proyecto adelante.

(4)

(5)

SECCIÓN I: MEMORIA DEL PROYECTO

1. IDENTIFICACIÓN DEL PROYECTO ... 15

2. ORGANIZACIÓN DEL DOCUMENTO ... 15

3. MOTIVACIÓN ... 15

4. OBJETIVOS ... 16

5. ARQUITECTURA Y ENTORNO DEL SISTEMA ... 17

5.1 ARQUITECTURA ... 17

5.2 ENTORNO DEL SISTEMA... 19

6. TECNOLOGIAS EMPLEADAS ... 19

7. METODOLOGIA EMPLEADA ... 22

8. PLANIFICACION ... 26

8.1 PLANIFICACIÓN INICIAL ... 27

8.2 PLANIFICACIÓN REAL ... 29

8.3 COMPARACIÓN Y CONCLUSIONES ... 31

9. COSTES ... 33

9.1 COSTES DE LOS RECURSOS HUMANOS ... 33

9.2 COSTE DE HARDWARE... 34

9.3 COSTE DEL SOFTWARE... 34

10. CONSIDERACIONES ... 35

10.1 DISEÑO ... 35

10.1.1 Carrito de la compra ... 35

10.1.2 Arquitectura de la aplicación ... 35

10.1.3 Productos, Marcas y Categorías ... 36

10.2 IMPLEMENTACIÓN ... 36

10.2.1 Métodos de pago ... 36

11. AMPLIACIONES ... 38

11.1 GESTION DE PROVEEDORES ... 38

11.2 GESTIÓN DE CONTABILIDAD ... 38

11.3 PAGO CON TARJETA ... 38

11.4 GESTION DE OFERTAS ... 40

11.5 GESTION DE ELIMINACIÓN DE CATEGORIAS O MARCAS ... 40

11.6 FACTURAS ... 41

12. CONCLUSIONES ... 41

13. BIBLIOGRAFIA ... 42

SECCIÓN II: MANUAL TÉCNICO

ANALISIS DEL SISTEMA ... 47

1. DIAGRAMAS DE CASOS DE USO DEL SISTEMA ... 47

1.1 Caso de uso “Administración Carrito de la compra” ... 47

1.1.1 Subcaso de uso “Añadir Artículo” ... 48

1.1.2 Subcaso de uso “Eliminar Artículo” ... 49

1.1.3 Subcaso de uso “Editar Artículo” ... 50

1.1.4 Subcaso de uso “Vaciar Carrito” ... 50

1.1.5 Subcaso de uso “Ver Contenido”... 51

1.2 Caso de uso “Administración de Categorías” ... 51

1.2.1 Subcaso de uso “Editar Categoría” ... 52

(6)

1.2.4 Subcaso de uso “Consultar Categoría” ... 54

1.3 Caso de uso “Administración de Clientes” ... 55

1.3.1 Subcaso de uso “Editar Cliente” ... 56

1.3.2 Subcaso de uso “Eliminar Cliente”... 57

1.3.3 Subcaso de uso “Añadir Cliente” ... 57

1.3.4 Subcaso de uso “Consultar Clientes” ... 58

1.4 Caso de uso “Administración de Direcciones” ... 59

1.4.1 Subcaso de uso “Editar Direccion”... 60

1.4.2 Subcaso de uso “Eliminar Dirección” ... 60

1.4.3 Subcaso de uso “Añadir Dirección” ... 61

1.4.4 Subcaso de uso “Consultar Direcciones” ... 62

1.5 Caso de uso “Administración de Información” ... 63

1.5.1 Subcaso de uso “Consultar Datos” ... 64

1.5.2 Subcaso de uso “Editar Datos” ... 64

1.6 Caso de uso “Administración de Marcas” ... 65

1.6.1 Subcaso de uso “Editar Marca” ... 66

1.6.2 Subcaso de uso “Eliminar Marca” ... 67

1.6.3 Subcaso de uso “Añadir Marca” ... 67

1.6.4 Subcaso de uso “Consultar Marcas” ... 68

1.7 Caso de uso “Administración de Pedidos” ... 69

1.7.1 Subcaso de uso “Editar Pedido” ... 70

1.7.2 Subcaso de uso “Eliminar Pedido” ... 70

1.7.3 Subcaso de uso “Consultar Pedido” ... 71

1.8 Caso de uso “Administración de Productos” ... 71

1.8.1 Subcaso de uso “Editar Producto” ... 72

1.8.2 Subcaso de uso “Eliminar Producto” ... 73

1.8.3 Subcaso de uso “Añadir Producto” ... 74

1.8.4 Subcaso de uso “Consultar Productos” ... 74

1.8.5 Subcaso de uso “Consultar Productos sin stock” ... 75

1.9 Caso de uso “Buscar Productos”... 75

1.10 Caso de uso “Consultar Productos” ... 76

1.10.1 Subcaso de uso “Consultar por Categoría” ... 77

1.10.2 Subcaso de uso “Consultar por Marca” ... 78

1.11 Caso de uso “Desconectar” ... 79

1.12 Caso de uso “Iniciar sesión” ... 80

1.13 Caso de uso “Recordar Contraseña” ... 81

1.14 Caso de uso “Registrarse” ... 82

1.15 Caso de uso “Realizar Pedido” ... 83

1.16 Caso de uso “Pagar” ... 84

2.DIAGRAMAS DE INTERACCIÓN CONCEPTUALES ... 86

2.1 Escenario 1.1: “Añadir artículo al carrito de la compra” ... 86

2.2 Escenario 1.2: “Eliminar artículo del carrito de la compra” ... 87

2.3 Escenario 1.3: “Editar artículo del carrito de la compra” ... 88

2.4 Escenario 1.4: “Vaciar artículo del carrito de la compra” ... 89

2.5 Escenario 1.5: “Ver contenido del carrito de la compra” ... 90

2.6 Escenario 2.1: “Editar categoría” ... 91

2.7 Escenario 2.2: “Eliminar categoría” ... 92

2.8 Escenario 2.3: “Añadir categoría” ... 93

2.9 Escenario 2.4: “Consultar categoría” ... 94

2.10 Escenario 3.1: “Editar cliente” ... 95

2.11 Escenario 3.2: “Eliminar cliente” ... 96

(7)

2.15 Escenario 4.3: “Añadir dirección” ... 100

2.16 Escenario 4.4: “Consultar dirección” ... 101

2.17 Escenario 5.1: “Consultar datos” ... 102

2.18 Escenario 5.2: “Editar datos” ... 103

2.19 Escenario 6.1: “Editar marca” ... 104

2.20 Escenario 6.2: “Eliminar marca” ... 105

2.21 Escenario 6.3: “Añadir marca” ... 106

2.22 Escenario 6.4: “Consultar marca” ... 107

2.23 Escenario 7.1: “Editar pedido” ... 108

2.24 Escenario 7.2: “Eliminar pedido” ... 109

2.25 Escenario 7.3: “Consultar pedido” ... 110

2.26 Escenario 8.1: “Editar producto” ... 111

2.27 Escenario 8.2: “Eliminar producto” ... 112

2.28 Escenario 8.3: “Añadir producto” ... 113

2.29 Escenario 8.4: “Consultar producto” ... 114

2.30 Escenario 8.5: “Consultar productos sin stock” ... 115

2.31 Escenario 9: “Buscar producto” ... 116

2.32 Escenario 10: “Consultar productos” ... 117

2.33 Escenario 10.1: “Consultar producto por categoría” ... 118

2.34 Escenario 10.2: “Consultar producto por marca” ... 119

2.35 Escenario 11: “Desconectar” ... 120

2.36 Escenario 12: “Iniciar sesión” ... 121

2.37 Escenario 13: “Recordar contraseña” ... 122

2.38 Escenario 14: “Registrarse”... 123

2.39 Escenario 15: “Realizar pedido” ... 124

2.40 Escenario 16: “Pagar” ... 125

3. DIAGRAMAS DE NAVEGABILIDAD... 126

3.1 Diagrama genérico ... 126

3.2 Diagrama para un Usuario Registrado ... 127

3.3 Diagrama para un Usuario Administrador ... 127

3.4 Diagrama para Realizar Pedido ... 131

4. MODELADO DE DATOS ... 132

4.1 Modelo Entidad-Relación ... 132

4.1.2 Entidades ... 132

4.1.3 Relación entre las entidades ... 133

4.2 Modelo Relacional ... 138

4.3 Consideraciones y Restricciones impuestas ... 144

4.4 TABLAS DE LA BASE DE DATOS ... 147

4.5 DICCIONARIO DE DATOS ... 149

4.6 DIAGRAMA DE CLASES ... 151

5. PRUEBAS DE SOFTWARE ... 153

5.1 Login en la aplicación web... 153

5.2 Contacto ... 154

5.3 Detalle Producto ... 155

5.4 Carrito ... 156

5.5 Recordar contraseña ... 156

5.6 Buscar productos... 157

5.7 Registro ... 157

5.8 Administración de usuario ... 160

5.8.1 Editar Dirección y Nueva Dirección ... 160

(8)

5.9.1 Administración de productos ... 164

5.9.2 Administración de marcas ... 165

5.9.3 Administración de Categorías ... 166

5.9.4 Administración de productos con no stock ... 167

SECCIÓN III: MANUAL DE USUARIO

MANUAL DE USUARIO ... 171

1. Manual de Instalación ... 171

1.1 Instalación de SQL Server 2008 R2 ... 171

1.2 Instalación de Visual Studio 2010 Ultimate ... 177

1.3 Crear base de datos ... 182

1.4 Desplegar aplicación en IIS ... 184

2. Manual de la aplicación ... 189

2.1 Inicio de la aplicación ... 189

2.2 Alta de Usuario ... 190

2.2.1 Login de Usuario ... 190

2.2.2 Registro de Usuario ... 192

2.2.3 Recordar contraseña ... 196

2.3 Contacto ... 198

2.4 Búsqueda de productos ... 199

2.5 Marcas ... 200

2.6 Categorías ... 202

2.7 Añadir productos al carrito de la compra ... 205

2.7.1 Manera unitaria ... 205

2.7.2 Mayor de uno ... 207

2.8 Carrito de la compra ... 208

2.8.1 Editar artículo del carrito de la compra ... 208

2.8.2 Borrar artículo del carrito de la compra ... 209

2.8.3 Vaciar el carrito de la compra ... 211

2.9 Realizar pedido ... 211

2.9.1 Selección de direcciones ... 212

2.9.2 Pago en PayPal ... 214

2.9.2.1 Cancelación del pedido ... 214

2.9.2.2 Pago con cuenta Sandbox PayPal ... 215

2.9.2.3 Pago con tarjeta ... 216

2.10 Panel de administración para rol Usuario ... 219

2.10.1 Pedidos ... 219

2.10.2 Direcciones ... 220

2.10.2.1 Consultar direcciones ... 220

2.10.2.2 Editar una dirección ... 221

2.10.2.3 Añadir una dirección ... 221

2.10.2.4 Borrar una dirección ... 222

2.10.3 Información ... 223

2.10.3.1 Consultar información ... 223

2.10.3.2 Editar Información ... 224

2.11 Panel de administración para el rol Administrador ... 225

2.11.1 Administración de productos ... 226

2.11.1.1 Añadir un producto ... 227

2.11.1.2 Editar un producto ... 229

2.11.1.3 Borrado de un producto ... 230

(9)

2.11.2.3 Editar una marca ... 232

2.11.2.4 Borrado de una marca ... 233

2.11.3 Administración de categorías ... 234

2.11.3.1 Consultar categorías ... 234

2.11.3.2 Insertar una categoría ... 235

2.11.3.3 Editar una categoría ... 235

2.11.3.4 Borrar una categoría ... 236

2.11.4 Administración de clientes ... 238

2.11.4.1 Consulta de clientes ... 238

2.11.4.2 Editar un cliente ... 238

2.11.4.3 Borrar un cliente ... 239

2.11.5 Administración de pedidos ... 239

2.11.5.1 Consulta de pedidos ... 239

2.11.5.2 Editar un pedido... 240

2.11.5.3 Borrar un pedido ... 241

2.11.6 Administración de productos con no stock ... 242

2.11.6.1 Editar un producto ... 242

2.11.6.2 Consulta de productos ... 243

2.11.6.3 Borrar un producto ... 243

(10)

(11)

(12)

(13)

1. IDENTIFICACIÓN DEL PROYECTO

Titulo: Fla vo rs o f th e S ta tes “S a b o rea lo s estad o s” Autor: Carlos Aguado García

Tutor: José Vicente Álvarez

2. ORGANIZACIÓN DEL DOCUMENTO

La documentación entregada constará de 3 partes y un CD-ROM.

 Memoria del proyecto

En esta sección, se abordarán temas generales acerca del proyecto como las herramientas, arquitectura, metodología, motivaciones, planificaciones y presupuestos.

 Manual Técnico

Los puntos a tratar en esta sección será desde una manera mucho más técnica, los requisitos, análisis, diseño, implementación y pruebas necesarias para el desarrollo de la aplicación web.

 Manual de Usuario e Instalación

El manual de instalación dejará claro qué es lo imprescindible para poder hacer funcionar dicha aplicación web y la manera de configurar todo el software necesario.

El manual de usuario, hará un recorrido por toda la aplicación web, viendo parte por parte cuales son las funcionalidades de la web, como su manera de uso.

 CD-ROM

En él se adjuntarán los siguientes directorios:

 Instalables: donde se tendrá todo el Software a instalar, necesario para probar nuestra aplicación.

 Flavors of the States: donde se tendrá la carpeta a publicar para poder ver la aplicación web.

 Código Fuente: que contendrá el código fuente de la aplicación.

 Documentación: en el que se encontrará 4 archivos con extensión PDF. Uno que será el presente documento, y otros 3 documentos PDF donde cada uno representará cada una de las partes del documento (Memoria, Manual Técnico y Manual de Usuario).

3. MOTIVACIÓN

Actualmente, la forma de hacer negocios ha cambiado y a la hora de la compra venta de todo tipo de artículos, la opción online es la más aceptada, cómoda y aunque a primera vista no se reconozca, más segura.

La falta de tiempo y comodidad del usuario final, ha hecho que prácticamente todo tipo de negocio tenga ya su propio sitio web en el que el cliente pueda tener los productos que necesita sin moverse de casa.

Personalmente, aunque en mi carrera profesional he participado en numerosas aplicaciones de gestión de diverso ámbito, tenía la necesidad de hacer una aplicación de gestión desde 0 por mí mismo y que intentara aglomerar mi conocimiento tanto en la Universidad como en los años que he estado trabajando para el sector.

(14)

Flavors of the States

La idea de hacer una web de compra de productos alimenticios americanos viene del hecho de que mi novia es norteamericana, la cual me introdujo al respecto en todos los productos americanos que ella echaba bastante de menos aquí en España y que en algunos momentos, nos fue bastante difícil de encontrar aquí. De ahí, la idea de hacer dicha web, que aunque hay algunos otros ejemplos de similares, intenté hacer algo más intuitiva dicha web y adaptada a mi gusto personal.

4. OBJETIVOS

El objetivo de este proyecto es desarrollar una aplicación web de venta de productos alimenticios americanos, mediante una interfaz que sea intuitiva y de fácil uso.

El sistema se encargará de validar el acceso de los usuarios a la aplicación web, donde se tendrán dos posibles perfiles: Usuario y Administrador.

Estas son las operaciones que cada uno de los perfiles puede hacer:

Usuario

• No registrado

o Navegación libre por la página web.

o Búsquedas sobre la web de productos.

o Mandar un correo a la tienda, expresando cualquier comentario o duda.

o Podrá registrarse en la página web, previa validación de sus datos. • Registrado

o Navegación libre por la página web.

o Búsquedas sobre la web de productos.

o Mandar un correo a la tienda, expresando cualquier comentario o dudas.

o Podrá hacer uso de la funcionalidad de ‘Olvido de Contraseña’.

o Gestionar su información de contacto personal.

o Consultar su historial de pedidos.

o Realizar un pedido pagando mediante PayPal.

o Gestionar las direcciones asociadas a su perfil. Administrador

• Navegación libre por la página web. • Búsquedas sobre la web de productos.

• Gestionar los productos (Insertar, Editar y Eliminar cualquier detalle del producto). • Gestionar las marcas (Insertar, Editar y Eliminar cualquier detalle de las marcas) • Gestionar las categorías (Insertar, Editar y Eliminar cualquier detalle de las categorías) • Gestionar los clientes (editar su rol, dar de baja o dar de alta)

• Gestionar los pedidos (editar el estado del pedido, eliminar o hacer un seguimiento)

• Cualquier otra función que pueda tener un Cliente aunque se presuponga obviamente que no va a hacer, como realizar un pedido.

(15)

5. ARQUITECTURA Y ENTORNO DEL SISTEMA

5.1 ARQUITECTURA

La arquitectura de 3 capas es un estilo de programación, cuyo objetivo primordial es la separación de la capa de presentación, la capa de negocio y la capa de datos.

En éste proyecto, la arquitectura va un poco más allá y se desglosa un grado más, donde podemos tener una extra capa, que es utilizada por las otras 3 capas.

Esta capa es la capa de entidades, se hace de esta manera para tener una mayor separación, claridad, limpieza y mantenimiento.

A continuación un detalle de cada una de las capas:

- Capa de presentación

o Es la capa que ve el usuario, presenta el sistema al usuario, le comunica la información del usuario en un mínimo proceso.

o Esta capa se comunica únicamente con la capa de negocio. También es conocida como ‘interfaz gráfica’ y debe ser amigable para el usuario.

- Capa de Negocio

o Donde se reciben las peticiones de usuario y se envían las respuestas tras el proceso. Es aquí donde se establecen las reglas que han de cumplirse.

o Se comunica con la capa de presentación, para recibir las solicitudes y presentar los resultados, y con la capa de datos, para solicitar al gestor de base de datos para almacenar o recuperar datos de él.

- Capa de datos

o Capa donde residen los datos y es la encargada de acceder a los mismos. Formada por un gestor de datos, que almacenan todos los datos, se reciben solicitudes de

almacenamiento o recuperación de información desde la capa de negocio.

(16)

Flavors of the States

Fig 1. Arquitectura básica de 3 capas

Se puede entender mejor esta estructura con la siguiente imagen, partiendo del concepto 3 capas, se tiene:

Fig 2. Concepto de arquitectura 3 capas avanzada

(17)

La capa de entidades es utilizada por las 3 capas (Presentación, Negocio y Acceso a datos).

Fig 3. Uso de capa entidades por el resto de capas

5.2 ENTORNO DEL SISTEMA

El entorno de desarrollo integrado (IDE) de Visual C# es un conjunto de herramientas de desarrollo expuestas a través de una interfaz de usuario común. Algunas de las herramientas se comparten con otros lenguajes de Visual Studio, y otras, como el compilador de C#, son únicas de Visual C#.

Un IDE es un entorno de programación que ha sido empaquetado como un programa de aplicación; es decir, consiste en un editor de código, un compilador, un depurador y un constructor de interfaz gráfica (GUI). Los IDEs pueden ser aplicaciones por sí solas o pueden ser parte de aplicaciones existentes.

Los IDE proveen un marco de trabajo amigable para la mayoría de los lenguajes de programación tales como C++, PHP,Python, Java, C#, Delphi, Visual Basic, etc. En algunos lenguajes, un IDE puede funcionar como un sistema en tiempo de ejecución, en donde se permite utilizar el lenguaje de

programación en forma interactiva, sin necesidad de trabajo orientado a archivos de texto. En este caso, el IDE utilizado es Microsoft Visual Studio 2010 (como se describe en la siguiente sección).

6. TECNOLOGIAS EMPLEADAS

Para el correcto desarrollo de nuestra página web, se han utilizado las siguientes herramientas.

• HTML

Acrónimo ingles de Hyper Text Markup Language (lenguaje de marcación de hipertexto), es un lenguaje informático diseñado para estructurar textos y presentarlos en forma de hipertexto, que es el formato estándar de las páginas Web.

Es un lenguaje muy sencillo que a base de etiquetas nos permite presentar el texto de una manera ordenada y agradable, con enlaces que nos conducen a otros documentos o fuente de información relacionadas, y con inserciones multimedia.

(18)

Flavors of the States

• JavaScript

JAVA Script es un lenguaje interpretado, multiplataforma, orientado a eventos con manejo de objetos, cuyo código se incluye directamente en el mismo documento, usado para el desarrollo de aplicaciones cliente-servidor en paginas HTML.

Esta tecnología permite dar respuesta a eventos iniciados por el usuario, tales como la entrada de un formulario o pinchar en un enlace. La verificación y validación de los datos de usuario se producen en el lado del cliente, no siendo necesario enviar ninguna información al servidor. Después de ser chequeadas, pueden ser enviadas al servidor.

• jQuery

jQuery es una biblioteca de JavaScript que permite simplificar la manera de interactuar con los documentos HTML, manipular el árbol DOM, manejar eventos, desarrollar animaciones (FLV) y agregar interacción con la técnica AJAX a páginas web.

jQuery es software libre y de código abierto y al igual que otras bibliotecas, ofrece una serie de funcionalidades basadas en JavaScript que de otra manera requerirían de mucho más código, es decir, con las funciones propias de esta biblioteca se logran grandes resultados en menos tiempo y espacio.

jQuery consiste en un único fichero JavaScript que contiene las funcionalidades comunes de DOM, eventos, efectos y AJAX.

La característica principal de la biblioteca es que permite cambiar el contenido de una página web sin necesidad de recargarla, mediante la manipulación del árbol DOM y peticiones AJAX.

• C#

C# es el lenguaje orientado a objetos diseñado por Microsoft para su plataforma .Net Combina los mejores elementos de lenguajes como C++, Java, Visual Basic o Delphi. Aunque es posible escribir código para la plataforma .Net en muchos otros lenguajes, C# es el único que ha sido específicamente diseñado para ser utilizado en ella, por lo que programarla usando C# es mas sencillo e intuitivo que hacerlo con cualquier otro. Se le considera así, el lenguaje nativo de .Net poseyendo el compilador mas depurado y optimizado del .net Framework SDK.

Reduce problemas de legibilidad de código y conflicto de nombres, no admitiendo que ni funciones ni variables globales sean declaradas y todo el código debe definirse en definiciones de tipos de datos.

Soporta todas las características propias del paradigma de programación orientada a objetos como la encapsulación, herencia y polimorfismo.

Es orientada a componentes, incluyendo elementos propios del diseño de componentes, es decir, lo que en otros lenguajes serían construcciones complejas solo serían propiedades, eventos o atributos.

Tiene gestión automática de memoria y un sistema de tipos unificado donde todos los tipos de dato derivan de una clase base común llamada System.Object.

Comparando C# con PHP, se podría decir que son lenguajes bastante diferentes y dos de los mas usados para la implementación de páginas web. Mientras que C# es un lenguaje optimizado y compilado para Windows y PHP es un lenguaje interpretativo y multiplataforma. Se dice que en principio un lenguaje compilado es más rápido que un leguaje interpretativo, pero personalmente la razón por la que el proyecto se haya encaminado con C# es que resulta un lenguaje mucho mas intuitivo y limpio que PHP, además de que ya partía con cierto conocimiento de C#, cosa que no era así con PHP.

(19)

o

Herramienta utilizada: Microsoft Visual Studio 2010 Ultimate

Microsoft Visual Studio es un entorno de desarrollo integrado (IDE, por sus siglas en inglés) para sistemas operativos Windows. Soporta varios lenguajes de programación tales como Visual C++, Visual C#, Visual J#, y Visual Basic .NET, al igual que entornos de desarrollo web como ASP.NET. aunque actualmente se han desarrollado las extensiones necesarias para muchos otros.

Visual Studio permite a los desarrolladores crear aplicaciones, sitios y aplicaciones web, así como servicios web en cualquier entorno que soporte la plataforma .NET (a partir de la versión .NET 2002). Así se pueden crear aplicaciones que se intercomuniquen entre estaciones de trabajo, páginas web y dispositivos móviles.

En concreto la versión utilizada en este proyecto es la Ultimate, aunque no es necesaria dicha versión para implementar la página web.

Visual Studio 2010 Ultimate: Conjunto completo de herramientas de gestión del ciclo de vida de una aplicación para los equipos que garantizan unos resultados de calidad, desde el diseño hasta la implementación. Ya sea creando nuevas soluciones o mejorando las aplicaciones existentes, Visual Studio 2010 Ultimate le permite llevar sus ideas a la vida en un número creciente de plataformas y tecnologías - incluyendo la nube y la computación paralela.

• Smartsheet

Es una aplicación web gratuita con la que poder gestionar las planificaciones en tiempo y desarrollar los diagramas de Gantt de forma sencilla, de nuestro proyecto.

• SQL

El lenguaje de consulta estructurado (SQL) es un lenguaje de base de datos normalizado, utilizado por los diferentes motores de bases de datos para realizar determinadas operaciones sobre los datos o sobre la estructura de los mismos.

o Herramienta utilizada: Microsoft SQL Server 2008 R2

 Es un sistema de administración de datos eficaz y confiable que ofrece un variado conjunto de características, protección de datos y rendimiento para aplicaciones embebidas, sitios web ligeros y almacenes de datos locales. Está basado en el modelo relacional.

• StarUML

StarUML es un proyecto de código abierto para desarrollar UML de una manera rápida, flexible, extensible, característica y disponible de manera gratuita.

Cabe decir que UML es un...

Lenguaje Unificado de Modelado (Unified Modeling Language) es el lenguaje de modelado de sistemas de software más conocido y utilizado en la actualidad; está respaldado por el OMG (Object Management Group). Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema. UML ofrece un estándar para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de negocio, funciones del sistema, y aspectos concretos como expresiones de lenguajes de programación, esquemas de bases de datos y compuestos reciclados. Se ha utilizado para hacer todos los diagramas UML del proyecto.

(20)

Flavors of the States

• Adobe PhotoShop CS5 Portable

Es un programa utilizado para armar, editar, componer, retocar y transformar imágenes.

Su gran facilidad para crear y manejar distintas capas superpuestas, permite combinar distintos objetos y efectos sin necesidad de modificar la imagen original como una superposición de transparencia, podemos corregir la imagen completa o parte de ella.

En concreto, para este proyecto ha sido útil para poder realizar la cabecera de la página.

• Entorno de desarrollo

IDE (Entorno de desarrollo integrado o Entorno de desarrollo interactivo) es una aplicación informática que provee de facilidades que abarcan el desarrollo de software para los programadores.

Normalmente, un IDE consta de un editor de código, compilador y debugueador. Algunos de ellos contienen aspectos de Intelli-sense (es la aplicación de autocompletar, mejor conocido por su

utilización en Microsoft Visual Studio entorno de desarrollo integrado. Además de completar el símbolo de los nombres que el programador está escribiendo, IntelliSense sirve como documentación y desambiguación de los nombres de variables, funciones y métodos de utilización de metadatos basados en la reflexión).

En este caso, el entorno de desarrollo o IDE utilizado es el propio Visual Studio 2010.

• Microsoft Word

Microsoft Word es un software destinado al procesamiento de textos.

Fue creado por la empresa Microsoft, y actualmente viene integrado en la suite ofimática Microsoft Office

Se ha utilizado para escribir la memoria del proyecto.

7. METODOLOGIA EMPLEADA

La Metodología de desarrollo de software en ingeniería de software es un marco de trabajo usado para estructurar, planificar y controlar el proceso de desarrollo en sistemas de información.

A lo largo del tiempo, una gran cantidad de métodos han sido desarrollados diferenciándose por su fortaleza y debilidad.

Para este proyecto, la primera opción que se barajó fue el uso del conocido ciclo de vida en cascada ya que es el más intuitivo y mas utilizado, aunque quizá no el más efectivo.

El modelo en cascada, uno de los primeros modelos de desarrollo de software que considera las diferentes actividades como fases separadas de tal forma que para iniciar una nueva actividad debe esperarse a la finalización de la actividad anterior.

Repasando sus cualidades se observó que ofrece más desventajas que ventajas: • Ventajas

o Modelo sencillo y disciplinado.

o Fácil de aprender y a utilizar y comprender su funcionamiento.

o Ayuda a detectar errores en las primeras fases a bajo coste.

o Minimiza gastos de planificación, ya que se realiza correctamente y sin problemas.

(21)

• Desventajas

o Necesidad de tener todos los requisitos al principio ya que lo normal es que el cliente no tenga perfectamente definidas las especificaciones surgiendo nuevos requisitos a lo largo de las diferentes etapas de desarrollo. Según este modelo hay que tener TODOS los requisitos en la primera etapa no pudiéndose llevar a cabo los requisitos que surjan una vez acabada la etapa de especificación.

o Es normal cometer errores en alguna de las etapas del proceso de desarrollo. Según este modelo cada vez que se identifique algún error cometido hay que volver a la etapa anterior y rehacer el trabajo.

o Los resultados y/o mejoras no son visibles progresivamente, el producto se ve cuando ya está finalizado, lo cual provoca una gran inseguridad por parte del cliente que quiere ir viendo los avances en el producto.

Dado que dicho modelo no se ajustaba a la forma de desarrollar el proyecto, y tras ver que el modelo de prototipo tampoco se ajustaba exactamente (ya que el desarrollo no se ha basado en una retroalimentación a través del cliente, al cual se le hayan dado entregables parciales), finalmente se optó por tomar el ciclo de vida en cascada retroalimentada.

No es más que una variante del ciclo de vida en cascada.

Fig 4. Modelo en cascada retroalimentado

(22)

Flavors of the States

Las ventajas que ofrece el ciclo de vida en cascada retroalimentada son:

• Ofrece la oportunidad de realizar cambios o evoluciones durante el ciclo de vida del Software. • Permite retroceder de una etapa a la anterior o incluso poder saltar a otras anteriores si es

requerido.

• No se tiene en cuenta la naturaleza evolutiva del software, se plantea como estático con requisitos bien conocidos y definidos desde el inicio.

Las desventajas que tiene son las siguientes:

• No conocer si la solución es correcta hasta estar cerca de su lanzamiento. • Hay poco tiempo para la resolución de fallos y tiene una depuración complicada. • No es muy frecuente que el cliente o usuario final explicite clara y completamente los

requisitos.

• Es posible que el cliente detecte algún error y debe ser paciente con el proceso. • Es sencilla y facilita la gestión de un proyecto.

Estas son las etapas de un proyecto:

 Ingeniería y Análisis del Sistema (Pre-Análisis)

 Esta fase consiste en conocer las reglas del negocio, sus necesidades y adquirir conocimiento acerca de las funciones propias del modelo de negocio.

 Lo que en este proyecto concordaría con los siguientes puntos:

 Estudio de páginas similares

• Donde se hará un recorrido por páginas web que suministren un servicio similar y de las que se obtendrán ideas o esquemas de lo que se espera de herramientas de compra on-line como la que implementaremos.

 Tecnologías a aplicar

• En este tema se tendrá que decidir por qué IDE y lenguaje de programación puede satisfacer más las necesidades tanto del cliente como del desarrollador.

• En este caso, por temas personales del desarrollador teniendo experiencia en este IDE, por la claridad en el desarrollo y por otros aspectos, se llegó a la confirmación de utilizar Visual Studio 2010 C# frente al archiconocido PHP.

 Análisis de Requisitos

 La fase de Análisis es directamente abordar la colección de necesidades identificadas en el pre-análisis y en base a ella proponer una solución, teniendo en cuenta la viabilidad tanto a nivel técnico como a nivel administrativo. ¿Qué se va a hacer?

 Será necesario hacer un diagrama Entidad-Relación y los Requerimientos estarán en el documento de ‘Especificación de Requerimientos del Sistema’ o ERS.

 Es la primera fase real de la consecución de un proyecto donde se extraen los requisitos y requerimientos, donde el cliente da el comportamiento y funcionalidad que se espera de esa página web.

(23)

 En este caso, no hay cliente físico y ha sido el mismo desarrollador el que ha establecido dichos requisitos y requerimientos, considerando que es lo fundamental para que la página web ofrezca lo que se ofrece en el mercado eCommerce, y además de una manera eficaz e intuitivo.

 Diseño

 La fase de diseño consiste en detallar la solución al problema que se ha identificado, es decir, se debe estructurar a nivel aplicación, red y base de datos como se va a abordar la solución, en el diseño se debe apoyar de diagramas de entidad relación para la bbdd, diagramas de clases entre otros. ¿cómo se va a hacer?

 Dar una arquitectura a nuestro proyecto significa dotar a nuestra página web de unos componentes o entidades, y tras ello mostrar la interacción entre dichos componentes y validación por medio de diagramas de interacción.

 Algunos ejemplos de diagramas necesarios serían: • Diagrama de clases

• Diagrama de base de datos • Diagrama de secuencia • Diagrama de estados

 En este proyecto, se dotará con diagramas de clases, base de datos y secuencia.

 Toda la parte de UML será implementado con la herramienta, StarUML.

 La parte de diseño de base de datos, se hará con la herramienta DB Designer 4.0.

 Codificación

 La fase de desarrollo es llevar a acciones el diseño que se ha elaborado previamente, es decir, se toma como ayuda un lenguaje de programación y de los software existentes para elaborar la aplicación que dará solución al problema identificado inicialmente.

 En este proyecto, la codificación se llevará a cabo con ASP.Net, con su lenguaje nativo C# en su IDE Visual Studio 2010.

 Dicha codificación se verá complementada por la adicción de código JavaScript y jQuery.

 Pruebas

 La fase de Pruebas consiste en una vez terminada la aplicación y su bbdd, teniendo el producto terminado se debe probar tanto a nivel individual como a nivel integrado y de esta manera se sabrá si la solución creada soluciona las necesidades planteadas al inicio del proceso de desarrollo.

 Dichas pruebas tienen que ser realizadas por usuarios que no hayan participado en la codificación del proyecto y que no vayan directamente a probar cosas en concreto, sino que desde el desconocimiento de la funcionalidad de la página web, muchas veces se encuentran errores que no podrían ser detectados por las pruebas unitarias de la persona que codifica.

 Serán necesarias pruebas unitarias de cada módulo o sección de la página web, como de ciclos enteros de pruebas que hagan que el ensamblado total de la aplicación funcione de la manera que se requiere.

(24)

Flavors of the States

 Mantenimiento

 Aquí se aborda todo lo referente al mantenimiento de la web, donde se puede hacer cambios en los requisitos establecidos al principio, desajustes en funcionalidades ya implementadas...en general cualquier tema que haga que la página web no trabaje como debiera, o cualquier cosa que el usuario final decida que es necesario cambiar, mejorar o hacer de nuevo.

 Es más general y normal, hoy en día, dar mantenimiento a una aplicación que crear nuevas aplicaciones.

8. PLANIFICACION

En esta sección se hará una comparativa entre la planificación inicial que se hizo para la consecución del proyecto y por otro lado la planificación real que mostrará como fue en realidad ese desarrollo del proyecto en todas y cada una de sus partes.

La planificación ha sido detallada con las siguientes fases de trabajo:

I. Estudio preliminar

a. Estudio de páginas webs similares b. Tecnologías a aplicar

II. Análisis

a. Estudio del problema b. Captura de Requerimientos c. Análisis de Requerimientos d. Identificación de tareas

III. Diseño

a. Modelado de clases b. Creación de base de datos

IV. Implementación

a. Implementación de Código b. Gráficos

V. Realización de Pruebas

VI. Documentación

a. Memoria del proyecto b. Manual Técnico c. Manual de Usuario

(25)

8.1 PLANIFICACIÓN INICIAL

Fig 5. Planificación Inicial

Fig 6. Diagrama de Gantt para la planificación inicial 1

(26)

Flavors of the States

(27)

8.2 PLANIFICACIÓN REAL

Fig 9. Planificación Real

Fig 10. Diagrama de Gantt para la planificación real 1

(28)

Flavors of the States

(29)

8.3 COMPARACIÓN Y CONCLUSIONES

La primera conclusión que se podría sacar al comparar ambas planificaciones, es que son muy aproximadas, y no puede ser de otra manera ya que el tiempo físico del que se disponía para la entrega del PFC no era amplia como para tener prácticamente ninguna demora, y poder tener el proyecto listo para su entrega en los plazos indicados.

Comparativa:

Nombre de la tarea Duración Inicial Duración Real

Flavors of the States 105 101

Estudio Preliminar 18 9

Estudio de paginas web similares 3 2

Tecnologías a aplicar 15 7

Análisis 12 10

Estudio del problema 2 2

Captura de Requerimientos 3 3

Análisis de Requerimientos 5 3

Identificación de Tareas 2 2

Diseño 7 10

Modelado de clases 3 5

Creación de la base de datos 4 5

Implementación 35 43

Implementación del código 30 40

Gráficos 5 3

Realización de Pruebas 7 4

Documentación 26 25

Memoria del proyecto 6 6

Manual Técnico 13 11

Manual de Usuario 7 8

Fig 13. Tabla representativa y comparativa de planificaciones en días

Esta tabla muestra la comparativa de las planificaciones, inicial y real.

Dicha comparación permite establecer la desviación que se ha dado en el desarrollo total del proyecto.

Fase a fase, se hará un desglose dando razones sobre los tiempos obtenidos.

Fases de desarrollo:

• Estudio Preliminar

o Inicialmente, se planificó quizá demasiado tiempo para esta fase ya que se preveía que habría que hacer un profundo análisis de lo que se quería mirando páginas web similares y teniendo en cuenta también, una curva de aprendizaje en cuanto a las tecnologías a aplicar. Curva que no fue tan grande, dado que el conocimiento que se tenía acerca de la plataforma fue esencial.

o El resultado es que se redujo a la mitad el tiempo planificado inicialmente.

(30)

Flavors of the States

• Análisis

o En cuanto a la fase del Análisis, se tardó básicamente lo que se planificó inicialmente, excepto para el análisis de los requerimientos dado que la subfase anterior de Captura de Requerimientos fue tan minuciosa y desglosada que no fue necesario dedicarle más tiempo.

• Diseño

o Los tiempos en la fase de diseño fueron muy similares a los planificados, salvo que debido a problemas con las claves foráneas entre las tablas, se experimentaron problemas que hizo retrasar mínimamente la planificación.

• Implementación

o En cuanto a la implementación, hay una gran desviación de días para el código ya que se subestimó dicha parte y no se tuvo en cuenta que había tecnologías que eran nuevas en la experiencia como desarrollador y se presentaron diversos problemas en la codificación.

• Realización de Pruebas

o Hay una mínima diferencia entre lo planificado y lo real dado que en la anterior fase de Implementación, se hicieron pruebas unitarias de los módulos a medida que se iba desarrollando con lo cual, las pruebas de ensamblado de módulos dio menos fallos de los esperables.

• Documentación

o Los plazos se han mantenido en general para los tres apartados de esta sección, pero hay que reseñar a este respecto que:

 Al ser la primera memoria tan extensa que el desarrollador hace, se han encontrado dificultades en especial en las dos primeras secciones de Memoria del Proyecto y Manual Técnico.



La tercera y última parte de Manual de Usuario fue la más sencilla, dado que es menos complicado explicar una página web que el mismo desarrollador ha hecho, funcionalmente.

(31)

9. COSTES

9.1 COSTES DE LOS RECURSOS HUMANOS

En la siguiente gráfica, se muestra el coste total del uso de los recursos humanos necesarios para llevar a consecución el proyecto.

Los recursos que se han tenido en cuenta son un Analista programador y un Programador, y se han estimado unos costes de 80 euros/dia y 50 euros/dia respectivamente.

Claramente el peso de los costes en el proyecto viene dado en la implementación, donde se echan más horas en total.

FASE DETALLE DURACION RECURSO COSTE

Estudio Preliminar 9

Estudio Paginas web similares 2 Analista 160

Tecnologias a aplicar 7 Analista 560

Subtotal 720

Analisis 10

Estudio del problema 2 Analista 160

Captura de requerimientos 3 Analista 240

Analisis de requerimientos 3 Analista 240

Identificación de tareas 2 Analista 160

Diseño 10

Modelado de clases 5 Analista 400

Creacion de la base de datos 5 Analista 400

Implementación 43

Implementación de código 40 Programador 2000

Gráficos 3 Programador 150

Subtotal 2150

Pruebas 4 Programador 200

Documentación 25

Memoria del Proyecto 6 Analista 480

Manual Técnico 11 Analista 880

Manual de Usuario 8 Programador 400

Subtotal 1760

TOTAL 6,430.00 €

Fig 14. Tabla representativa de costes del proyecto para RRHH

(32)

Flavors of the States

9.2 COSTE DE HARDWARE

En esta subsección se puede ver los gastos en hardware, donde básicamente se ha utilizado un único ordenador portátil y un dispositivo de almacenamiento externo.

DISPOSITIVO HARDWARE EMPLEADO COSTE USO COSTE REAL

Portátil Clónico 850 € 15% 127.50 €

CPU Intel Core 2 duo T7500

RAM 4 GB

Disco Duro 500 GB

Tarjeta Gráfica Integrada

Sistema Operativo Windows XP

Almacenamiento Externo Pendrive 32 GB 24 € 15% 3.60 €

TOTAL 131.10 €

Fig 15. Tabla representativa de costes de Hardware

9.3 COSTE DEL SOFTWARE

En esta apartado, se tienen los gastos ocasionados por el Software utilizado.

HERRAMIENTA COSTE DESCRIPCION USO

COSTE REAL

Windows XP 0

Sistema Operativo (Incluido en

portátil) 15% 0

Microsoft Word 2003 0 Editor de texto (Incluido en portátil) 15% 0

StarUML 0 Modelado UML 15% 0

Acrobat Reader 0 Lector de archivos PDF 15% 0

Smartsheet 0 Gestión de tiempos para proyectos 15% 0

DB Designer 0 Modelado de bases de datos 15% 0

Visual Studio 2010

Proffessional 630 € IDE .Net 15% 94.5

SQL Server 2008 R2 0 Gestor de BBDD 15% 0

Mozilla Firefox 0 Navegador Web 15% 0

Google Chrome 0 Navegador Web 15% 0

Adobe Photoshop CS5 879 € Diseño Gráfico 15% 131.85

TOTAL 226.35 €

Fig 16. Tabla representativa de costes totales de Software

9.4 COSTES TOTALES DE LA PÁGINA WEB

DESCRIPCION COSTE

Coste RRHH 6,430 €

Coste HW 131.10 €

Coste SW 226.35 €

TOTAL 6,787.45 €

Fig 17. Tabla representativa de costes totales del proyecto

(33)

10. CONSIDERACIONES

10.1 DISEÑO

10.1.1 Carrito de la compra

Cuando se hizo el diseño de las clases y la base de datos, se invirtió tiempo en como enfocar el tema del carrito de la compra en la página web.

En principio habría dos opciones:

- Crear una tabla Carrito, donde cada cierto tiempo, o en el momento que el usuario actualizase el carrito, se insertara en base de datos y se mantuviese actualizado.

o La única ventaja de esta opción, bajo mi punto de vista, es que cuando el usuario se logase en la página, actualizase su carrito y abandonase la página sin realizar ningún pedido, cuando se volviera a logar, tendría de nuevo esos artículos persistentes en su carrito y no tendría que volver a agregar dichos artículos.

o Las desventajas, es que habría un constante ataque a base de datos para actualizar datos en el carrito y que realmente, desde mi punto de vista, no tiene sentido guardar esta información en tablas.

- Guardar el carrito en sesión.

o De esta manera, no se ataca a base de datos constantemente.

o No es necesario por tanto, crear ninguna tabla en base de datos ni ningún mantenimiento.

o En la mayoría de las páginas web existentes, los carritos de la compra se guardan de esa manera, en el tiempo que la sesión dure antes de que caduque.

o Mientras que la sesión dure hasta que se haga el pedido (si es que se hace), las modificaciones se harán en sesión.

o Sólo cuando el cliente realice el pedido, se usarán esos datos del carrito de la compra para insertarlos en base de datos, en concreto en la tabla de Pedidos y de

DetallePedido.

Es la mejor opción por tanto, en cuestión de tiempos, accesibilidad y comodidad a la hora de desarrollar código, por lo que fue la opción escogida.

10.1.2 Arquitectura de la aplicación

La estructura usada para nuestra arquitectura sería N-Capas, en este caso, 4 capas:

- Interfaz de Usuario

o En este caso, esto será todas y cada una de las páginas *.aspx y todos los controles de usuario *.ascx existentes en el proyecto.

o Son los encargados de mostrar al usuario de manera gráfica, todo lo que se maneja por detrás.

(34)

Flavors of the States

- Lógica de Negocio

o Esta capa es la que contiene la lógica de la página.

o Tendrá unos procedimientos que son llamados desde el Interfaz de Usuario y que recibirán también como parámetro, esos objetos tipos Entidad creados.

o Estos procedimientos llamarán a su vez a la capa de datos, sin saber qué es lo que hace esa capa de datos.

- Acceso a Datos

o Esta capa es la que accede directamente a Base de datos, extrayendo la información necesaria en base de datos, CRUD (Create, Read, Update, Delete).

- Entidades

o Contiene todas las entidades que se utilizan en el proyecto (Productos, Categorías, Marcas…)

o Serán los objetos que serán creados en la Interfaz de Usuario y se mandarán como parámetros a la capa de negocio.

o Llamada también BEL, o Business Entity Layer.

o Contiene la estructura de la entidad, con sus get y set de atributos.

10.1.3 Productos, Marcas y Categorías

En este aspecto, es importante reseñar lo siguiente:

- El modelo relacional creado, relaciona estas tres tablas (Productos, Marcas y Categorías), por lo que hay tareas que el administrador ‘no puede hacer’ en primera instancia, como es:

o Eliminar una categoría que tiene productos asociados.

o Eliminar una marca que tiene productos asociados.

Para ambos casos, el usuario recibirá un mensaje en una ventana pop-up en el que se le dirá que no es posible hacer esa operación y que es necesario que los productos asociados a esa categoría o marca, sean actualizados a otra categoría o marca existente y una vez hecho esto, se podrá eliminar.

10.2 IMPLEMENTACIÓN

10.2.1 Métodos de pago

Para ésta página web, dado los tiempos que se tenían para desarrollar el proyecto y la complejidad de implantación de métodos de pago reales y/o dificultades para cumplir los requisitos de implantación, únicamente se ha implantado el método de pago con PayPal, que incluye el pago con tarjeta pero sin pasarela propia del banco asociado.

PayPal ofrece algo muy atractivo para los desarrolladores, ya que permite probar y ver cómo va a funcionar exactamente dicho método de pago sin realizar ninguna transacción económica real.

Lo que ofrece PayPal es un duplicado exacto del sitio activo PayPal, llamado Sandbox y que la única diferencia respecto a PayPal es que es un entorno de pruebas y que no hay transacciones reales, donde el dinero pase de unas manos a otras.

Este entorno de pruebas permite probar toda la integración antes de enviar transacciones al entorno activo de PayPal. Y puedes crear y administrar cuentas de prueba, en el que se asignarán cuentas de

(35)

banco y tarjetas de crédito ficticias asociadas a la página web y con las que se puede chequear todo detalle del pago con PayPal o con tarjeta de crédito a través de PayPal.

Cuando se finaliza el pago desde la página web, se hace la redirección hacia Sandbox PayPal donde se puede ver el detalle del pedido que el cliente va a realizar ya que contiene el detalle del carrito de la compra, con las unidades, precio unitario, precio total y se pide cuenta de Sandbox para poder realizar el pedido.

Fig 18. Pago con Paypal

Una vez pagado, haciendo clic en un enlace, se va a redireccionar de nuevo a la página web donde dependiendo del éxito o fracaso del pago, se mostrará un mensaje de confirmación de compra o de fallo en la compra.

Éste método de pago ofrece exactamente lo mismo que PayPal y da clara muestra de cómo va a funcionar PayPal cuando se quiera implementar.

El único cambio que sería necesario para actualizar de Sandbox PayPal a PayPal, sería cambiar únicamente la web de conexión.

Actualmente se conecta a :

https://www.sandbox.paypal.com/us/cgi-bin/webscr?

Habría que conectar simplemente hacia PayPal directamente:

https://www.paypal.com/us/cgi-bin/webscr?

Con este simple cambio, y obviamente usando una cuenta de PayPal existente y real (ya que las cuentas creadas en Sandbox son para pruebas y ficticias) se podría apuntar directamente a PayPal de manera real y todo debería funcionar de igual manera que lo está haciendo ahora mismo con Sandbox.

(36)

Flavors of the States

11. AMPLIACIONES

En esta sección, se explicará cuales podrían ser las futuras ampliaciones de dicha página web, que como toda página web, aplicación o software, siempre queda una puerta abierta a la posibilidad de mejorarlas o de hacerlas más completas.

11.1 GESTION DE PROVEEDORES

Esta sección podría ser una parte a añadir a la aplicación web, en la que se podría saber desde la página de administración del usuario Administrador, saber a qué proveedores hace falta hacer un pedido de determinados productos cuando no haya stock. Actualmente, sólo se le muestra al Administrador cuáles son los productos sin stock, pero se podrían agrupar por Proveedor y darle un detalle más claro y conciso que le ayudase en su labor administrativa.

11.2 GESTIÓN DE CONTABILIDAD

Esta idea abarcaría el darle la posibilidad al Administrador de tener unos informes en los que se reflejen la actividad económica de la página web.

En ella, se haría reflejo por semana, mes o año, los beneficios finales marcados por las ventas de productos a clientes menos la suma pagada a proveedores para tener productos en stock.

Daría una idea de contabilidad general de la página ya que actualmente no hay nada, que de un resultado de ventas que de al administrador fuentes para hacer un estudio de acercamiento al cliente.

11.3 PAGO CON TARJETA

Como para toda aplicación eCommerce, es necesario tener unas transacciones reales entre cliente y aplicación web para cerrar el ciclo de compra-venta on-line.

Tal y como ésta página web únicamente va a estar publicada en el servidor localhost, no es posible desarrollar un módulo real con métodos de pago, donde haya una transacción real de una tarjeta de crédito a nuestra cuenta asociada a la tienda on-line, sino que todo será de manera ficticia.

Una mejora en este aspecto, sería montar dicha pasarela para hacer un pago mediante tarjeta de crédito/debito, que no sea la propia que ofrece PayPal a clientes de la página web que no tengan una cuenta PayPal creada y operativa (que es la opción que actualmente está implementada).

Ésta mejora es bastante opcional, ya que éste sitio eCommerce puede ser totalmente funcional sin tener una pasarela de pago con banco, sino que simplemente es completamente suficiente lo que ofrece en su caso PayPal.

PayPal ofrece para ello, elegir un método de pago, sea PayPal o pago con tarjeta de crédito (Visa, MasterCard o American Express)

Este método de pago virtual mediante tarjeta se haría a través de una plataforma que haría un procesamiento de esas tarjetas desde Internet conectándose a las redes privadas de los sistemas que se quisiera dar como opciones de pago (VISA, MasterCard, American Express…). Este método permitiría a los clientes realizar compras utilizando su tarjeta y dichas operaciones se validarían en línea.

(37)

Estos serían los pasos a seguir:

- Una vez que el cliente tenga preparado su carrito de la compra con todos los artículos de su pedido, al finalizar el pedido se le preguntaría con qué método prefiere pagar.

- La página web redirigiría al servidor seguro del banco contratado y TPV del banco, la cantidad a cobrar para finalizar el pedido.

- El cliente introduciría sus datos, como número de tarjeta, fecha de expiración de la tarjeta y su número secreto. Todo ello iría al servidor del banco y se procesaría la petición.

- El dinero quedaría substraído de la cuenta del cliente e ingresado en la cuenta asociada a nuestra página web y a nuestro TPV.

- Tras un pago satisfactorio o no, devolvería el control a nuestra página web donde se tramitará dicha respuesta de manera conveniente en nuestra base de datos.

Para ésta página web se intentó implementar dicha solución pero para ello hay que cumplir numerosos requisitos y también conlleva una gran complejidad en cuanto a la codificación.

Algunos de los requisitos que conlleva son:

- Que la página web exista, es decir, tenga un dominio asociado, un host en el que esté alojada. - Tras ello tiene que haber un contrato ente comerciante y banco al que se quiera asociar ésta

forma de pago, contratando así un TPV virtual (Terminal de punto de venta).

- Dicho TPV virtual tendrá un costo inicial, una coste de mantenimiento y una comisión por transacción y dependiendo del volumen de venta.

Dado que todo esto no era posible, se optó por otras opciones como un método de pago TPV virtual ficticio por medio de compañías como DataCash.

DataCash es parte de MasterCard, y es una compañía de procesamiento de pagos que ofrece una forma de pago global y multicanal para asegurar que no hay fraude o riesgo en el manejo de servicios de pago on-line.

Dicha compañía, ofrece una versión ficticia (al igual que PayPal) para simular esos pagos mediante tarjeta de crédito antes de implementarlos en nuestra página web.

Finalmente, no se pudo implementar dado que no se aceptan páginas web que no estén alojadas en un host, y porque por su complejidad de implantación, conllevaría un coste en tiempo que dada la planificación del proyecto, es inviable.

Con todos estos inconvenientes que se encontraron durante el desarrollo, la única solución viable fue la implementación de todo el sistema de pago de PayPal que ofrece ambas cosas, pago con PayPal (si tienes cuenta operativa) y a través de tarjeta de crédito (si no tienes cuenta operativa PayPal).

(38)

Flavors of the States

Fig 19. Representa la manera alternativa dada por PayPal de pago con tarjeta de crédito

11.4 GESTION DE OFERTAS

Cabría la posibilidad de hacer un servicio de ofertas que se encargaría de mandar un correo con ofertas personalizadas a los clientes, dependiendo de los productos que esos clientes compran normalmente.

Para ello también sería necesario tener una parte de administración para el usuario, donde quede registrado de alguna manera un estudio de las categorías o las marcas que mas compra ese determinado usuario.

De igual manera, para todos los usuarios en general, podría haber una sección de ofertas sin tener ningún tipo de personalización en clientes.

11.5 GESTION DE ELIMINACIÓN DE CATEGORIAS O MARCAS

Una mejora respecto a la eliminación de categorías o marcas, es que, cuando se intente eliminar una categoría o marca con productos asociados, en vez de simplemente mostrar al usuario un mensaje indicando que no es posible eliminarlos hasta que se actualicen los productos a otras marcas o categorías, que haga lo siguiente:

- Mostrar una ventana pop-up con un grid en el que salgan todos los productos afectados por esa eliminación y se pueda actualizar a otra marca o categoría en ese mismo momento, y tras ello esa categoría o marca pueda ser eliminada.

(39)

11.6 FACTURAS

Este apartado trata acerca de las facturas hechas para los pedidos que los clientes puedan realizar en la página web.

Lo que la página web ofrece ahora mismo, es mandar un correo a la dirección electrónica del usuario con todo el detalle del pedido que se acaba de hacer, que es básicamente una factura pero sin el formato de una factura formal.

La mayoría de los sitios web actuales, simplemente mandan un correo electrónico dando el detalle del pedido, pero una posible ampliación podría ser precisamente esto, hacer un apartado que pusiera los mismos detalles del pedido en una plantilla en vez de un email, y que lo exportase a pdf.

Cuando se hace un pedido, se piden dos direcciones, la de envío y la de facturación, que pueden ser la misma o no. La aplicación estaría ya preparada para que se le añadiese dicha funcionalidad ya que se tiene todo lo necesario, detalles del pedido y dirección de facturación.

Al igual que el pedido (si fuese una página web real) sería enviado a la dirección de envío, la factura sería enviada a la dirección de facturación. Actualmente, la web no hace nada realmente con esa dirección de facturación, únicamente deja todo detallado de manera histórica para los pedidos

realizados.

12. CONCLUSIONES

El proyecto realizado representa la síntesis de los conocimientos que el desarrollador adquirió en la Universidad en su momento y de la experiencia que ha adquirido en su vida profesional.

A pesar de ello, Flavors of the States ha sido la primera aplicación web completa que el desarrollador ha hecho y ha servido para enfrentarse a todas las fases de un proyecto, cosa que en su vida profesional no ha sucedido, ya que en la vida real cuando trabajas para una compañía, tu dedicación (dependiendo de tu categoría) queda relegada a una determinada área, sea diseño o codificación y no a todas las fases que un proyecto puede tener.

Ha servido para darse cuenta cómo de importante es un buen análisis y diseño de la aplicación, antes de ponerse a codificar directamente sin analizar todo de la mejor manera y viendo ventajas e inconvenientes. Ya que un mal análisis de un requisito, o un mal diseño de clases o de base de datos puede convertirse en un quebradero de cabeza de grandes dimensiones cuando se descubre un error en esas partes cuando el proyecto puede estar ya bastante avanzado. Todo ello puede suponer un gran cambio en el coste del desarrollo y en los tiempos de entrega, con lo que quizá en mi caso, hubiera sido interesante hacer un análisis más extenso inicialmente para evitar algunos de los problemas que se han podido encontrar durante la codificación del proyecto.

(40)

Flavors of the States

13. BIBLIOGRAFIA

Paginas de apoyo para el desarrollo de la página web

http://msdn.microsoft.com/ http://www.dotnetspider.com/ http://www.c-sharpcorner.com/ http://www.codeproject.com http://www.asp.net/

http://net.tutsplus.com/ http://support.microsoft.com

Métodos de pago

https://developer.paypal.com www.datacash.com

jQuery

https://developer.paypal.com

Otras páginas a las que he recurrido

http://stackoverflow.com http://www.free-css.com/ http://www.w3schools.com http://v4.aspnettutorials.com/

Webs similares

http://www.myamericanmarket.com/

(41)

(42)

(43)

(44)

(45)

ANALISIS DEL SISTEMA

1. DIAGRAMAS DE CASOS DE USO DEL SISTEMA

1.1 Caso de uso “Administración Carrito de la compra”

 Objetivo

Permitir que el usuario, sea registrado o no, tenga acceso a su carrito de la compra. Las operaciones que el cliente podrá hacer en dicho carrito serán las siguientes:

• Añadir productos en tiempo real

• Modificar las unidades de los productos existentes en el carrito • Eliminar un producto existente en el carrito

• Vaciar el carrito, donde todos los productos serán eliminados. • Ver el contenido del carrito de la compra.

 Actor

Usuario no registrado Usuario Registrado

 Flujo de evento principal

El usuario navega por la aplicación web, y añadirá los productos que considere necesarios y añadiendo las unidades que se consideren.

La aplicación web añade dichos productos al carrito y finalmente, el usuario puede (o no) hacer efectivo el pedido con el contenido del carrito.

 Flujo de eventos alternativo

• El usuario puede querer consultar el contenido del carrito de la compra.

o La aplicación web muestra el contenido del carrito. • El usuario puede eliminar un artículo del carrito.

o La aplicación actualiza el carrito de la compra. • El usuario puede añadir un articulo al carrito.

o La aplicación actualiza el carrito de la compra. • El usuario puede modificar un artículo.

o La aplicación actualiza el carrito de la compra. • El usuario puede vaciar el carrito.

o La aplicación actualiza el carrito de la compra.

 Flujo de eventos excepcional

• Fallo de conexión

(46)

Flavors of the States

Fig 1.1. Diagrama caso de uso ‘Administración del carrito de la compra’

1.1.1 Subcaso de uso “Añadir Artículo”

 Objetivo

Permite al usuario añadir un artículo al carrito de la compra, desde varios sitios en la aplicación web. Esta inserción de artículos puede ser de manera unitaria (es decir, añadiendo de uno en uno) desde los dos iconos que aparecen bajo cualquiera de los artículos (icono del carrito y botón) o desde la página de detalle de cualquiera de los productos, donde se puede insertar la cantidad del artículo que se precise.

 Actor

 Flujo de evento principal

1. El usuario hace una petición de listado de productos (por marca o por categoría) 2. La aplicación muestra dicho listado.

3. El usuario hace clic en el icono del carrito de compra o el botón Añadir.

4. La aplicación añade tantos artículos como veces se haga clic en cualquiera de los dos botones.

 Flujo de eventos alternativo

5. El usuario solicita ver el detalle de un producto en concreto. 6. La aplicación muestra el detalle del producto.

(47)

 Flujo de eventos excepcional

1..8 <Fallo de conexión>, la aplicación muestra un mensaje de error si fallase la conexión al realizar una operación.

3..4 y 7..8 <Stock Insuficiente>, si se intenta añadir más artículos que el stock disponible para ese producto, la aplicación mostrará un mensaje por pantalla en el que se comunicará al cliente de que no hay suficiente stock.

 Escenarios

o Añadir artículo a carrito de la compra.

1.1.2 Subcaso de uso “Eliminar Artículo”

 Objetivo

Permitir al usuario eliminar un artículo del carrito de la compra que ya no se quiere tener.

 Actor

 Flujo de Eventos principal

1. El usuario hace clic en el icono de la papelera que está en el grid del carrito de la compra.

2. La aplicación pide confirmación al cliente acerca del borrado. 3. El usuario confirma.

4. La aplicación elimina dicho artículo y lo actualiza en tiempo real.

 Flujo de Eventos alternativo

5. El usuario hace clic en Editar el Artículo.

6. La aplicación deja en modo edición el grid del carrito de la compra. 7. El usuario introduce ‘0’ artículos para ese producto.

8. La aplicación elimina dicho producto del carrito y actualiza. 9. Cancelación del proceso

 Flujo de Eventos excepcional

1..9 <Fallo de conexión>

 Escenarios

(48)

Flavors of the States

1.1.3 Subcaso de uso “Editar Artículo”

 Objetivo

Permitir al usuario poder editar la cantidad del artículo en concreto perteneciente al carrito de la compra.

 Actor

1. El cliente hace clic en el icono de editar articulo 2. La aplicación lo pone al estado de edición.

3. El usuario introduce la cantidad de artículos que quiera. 4. La aplicación lo actualiza.

2..4 .. Cancelar el proceso.



E

scenarios

o Editar Artículo

1.1.4 Subcaso de uso “Vaciar C arrito”

 Objetivo

Permitir al usuario poder vaciar el carrito de forma rápida y en una sola acción, sin tener que ir uno a uno eliminando los artículos.

 Actor

1. El usuario solicita el vacío del carrito de la compra haciendo clic en el icono. 2. La aplicación pide confirmación para realizar el vacío del carrito.

3. El usuario confirma.

(49)

2 <Cancelar Proceso>

 Escenarios

o Vaciar carrito de la compra