TFG Aitor Urteaga Pecharroman

Universidad Carlos III de Madrid
Repositorio institucional e-Archivo http://e-archivo.uc3m.es

Trabajos acadmicos Trabajos Fin de Grado Escuela Politcnica Superior
2015-09
Aplicacin de la metodologa de
desarrollo gil Scrum para el desarrollo
de un sistema de gestin de empresas
Urteaga Pecharromn, Aitor
http://hdl.handle.net/10016/23750
Descargado de e-Archivo, repositorio institucional de la Universidad Carlos III de Madrid

Aplicacin de la metodologa de
desarrollo gil Scrum para el desarrollo
de un sistema de gestin de empresas
TRABAJO FIN DE GRADO
GRADO EN INGENIERA INFORMTICA
Madrid, Septiembre 2015
Autor: Aitor Urteaga Pecharromn.
Tutor: Javier Fernndez Muoz.

1|Pgina
Agradecimientos
A todas las personas que me han apoyado durante esta etapa universitaria,
especialmente en los momentos ms difciles, momentos en los que lo ms fcil
hubiese sido rendirse pero gracias a vuestra ayuda segu adelante.
Ahora finalmente he conseguido alcanzar la meta que me propuse hace aos y
tengo que reconocer no lo habra logrado sin vuestro apoyo.
Muchas gracias a todos por estar ah.
2|Pgina
Resumen
Este proyecto describe el desarrollo de un sistema de gestin de

empresas, tambin conocido como ERP. El cual se desarrolla empleando la
metodologa gil Scrum. El proyecto se divide en varias iteraciones en las
cuales se obtiene como resultado un prototipo. El sistema est compuesto
por una aplicacin cliente para uso del usuario y una base de datos
centralizada donde se almacenarn todos los registros relativos a la
empresa.
3|Pgina
Abstract
This project describes the development of a enterprise resource

planning, also known as ERP. Which is developed using agile methodology
Scrum. The project is divided into several iterations in which you get as a
result a prototype. The system consists of a client application to use the
user and a centralized database where all records relating to the company
store.
4|Pgina
Contenido
Captulo 1: Introduccin ............................................................................. 9
Contexto ................................................................................................. 9
Motivaciones ........................................................................................ 10
Objetivo ................................................................................................ 11
Estructura ............................................................................................. 12
Captulo 2: Estado del arte ....................................................................... 13
Aplicaciones de gestin empresarial .................................................... 13
ERP .................................................................................................... 13
Ciclo de vida...................................................................................... 14
Implementacin Big Bang ................................................................ 15
Implementacin gil ........................................................................ 18
Anlisis .............................................................................................. 18
Realizacin del Sprint ....................................................................... 19
Productos existentes ........................................................................ 20
Herramientas de desarrollo ................................................................. 23
Microsoft Windows 8.1 .................................................................... 24
Visual Studio 2013 ............................................................................ 24
SGBD ................................................................................................. 25
Metodologa de desarrollo ................................................................... 26
Qu es Scrum? ................................................................................ 26
Qu caracteriza a Scrum? ............................................................... 27
Los papeles de Scrum ....................................................................... 28
Captulo 3: Anlisis del sistema ................................................................ 31
5|Pgina
Definicin.............................................................................................. 32
Historias de usuario .............................................................................. 33
Tareas ................................................................................................... 38
Estimacin ............................................................................................ 49
Planning Poker .................................................................................. 50
Estimacin en el proyecto ................................................................ 50
Captulo 4: Desarrollo del sistema ........................................................... 53
Visin general ....................................................................................... 53
Arquitectura ......................................................................................... 54
Cliente - Servidor .............................................................................. 54
MVC .................................................................................................. 55
Capa Datos ........................................................................................ 58
Sprints ................................................................................................... 63
Sprint Planning ................................................................................. 64
Sprint 0 ............................................................................................. 65
Primer Sprint .................................................................................... 67
Segundo Sprint ................................................................................. 84
Tercer Sprint ..................................................................................... 93
Cuarto Sprint .................................................................................. 101
Captulo 5: Planificacin y presupuesto ................................................. 113
Planificacin ....................................................................................... 113
Presupuesto ........................................................................................ 114
Resumen de tiempo dedicado ....................................................... 114
Coste de personal ........................................................................... 115
Coste de Hardware ......................................................................... 115
6|Pgina
Coste de Software .......................................................................... 116
Resumen de costes ......................................................................... 116
Captulo 6: Conclusiones ........................................................................ 117
Desarrollos futuros ............................................................................. 119
Conclusiones personales .................................................................... 122
Anexo A: Manual de usuario .................................................................. 123
Anexo B: Bibliografa .............................................................................. 129
Ilustracin 1- ERP Ciclo de vida ................................................................ 14
Ilustracin 2 - Rendimiento del sistema................................................... 16
Ilustracin 3 - Proceso de implantacin de Big Bang ............................... 17
Ilustracin 4 - Procesos Scrum ................................................................. 29
Ilustracin 5 - Procesos Scrum (complejo) ............................................... 30
Ilustracin 6 - Cliente-Servidor ................................................................. 54
Ilustracin 7 - MVC ................................................................................... 56
Ilustracin 8 - Capas ................................................................................. 57
Ilustracin 9 - Capas desarrollo ................................................................ 70
Ilustracin 10 - Base de datos .................................................................. 70
Ilustracin 11 - Modelo base datos I ........................................................ 72
Ilustracin 12 - Modelo base de datos II .................................................. 73
Ilustracin 13 - Modelo base de datos III ................................................. 74
7|Pgina
Ilustracin 14 - Procedimiento buscar ..................................................... 75
Ilustracin 15 - Procedimiento insertar ................................................... 75
Ilustracin 16 - Procedimiento eliminar ................................................... 76
Ilustracin 17 - Procedimiento mostrar ................................................... 76
Ilustracin 18 - Procedimiento editar ...................................................... 76
Ilustracin 19 - Conexin base de datos .................................................. 77
Ilustracin 20 - Interfaz de usuario Grupo de artculos ........................... 80
Ilustracin 21 - Interfaz de usuario Artculos ........................................... 81
Ilustracin 22 - Interfaz de usuario Proveedores ..................................... 87
Ilustracin 23 - Interfaz de usuario Centros ............................................. 89
Ilustracin 24 - Interfaz de usuario Stocks ............................................... 90
Ilustracin 25 - Interfaz de usuario Ventas .............................................. 96
Ilustracin 26 - Interfaz de usuario Empleados ....................................... 97
Ilustracin 27 - Interfaz de usuario Clientes ............................................ 98
Ilustracin 28 - Interfaz de usuario Compras ......................................... 104
Ilustracin 29 - Interfaz de usuario Inicio............................................... 105
Ilustracin 30 - Interfaz de usuario Venta rpida .................................. 106
Ilustracin 31 - Interfaz de usuario Compra rpida ............................... 106
Ilustracin 32 - MS Excel Obj. Library..................................................... 107
Ilustracin 33 - Interfaz de usuario Importar ......................................... 108
Ilustracin 34 - Diagrama de Gantt ........................................................ 113
Ilustracin 35 - Comparativa esfuerzos.................................................. 118
Ilustracin 36 - Partes aplicacin ........................................................... 120
8|Pgina
Captulo 1: Introduccin
El proyecto, en el cual se basa este documento, consiste en la utilizacin

de la metodologa gil Scrum en el desarrollo de un sistema de gestin de
pequeas empresas del tipo ERP. En este documento se describen las distintas
fases del proyecto as como el contexto que lo rodea en cuanto a tecnologas y
metodologas.
Contexto
Este proyecto se sita dentro del rea de los sistemas de informacin si
se tiene en cuenta si siguiente definicin:
Un sistema de informacin es un conjunto de elementos que

interactan entre s con el fin de apoyar las actividades de una empresa o
negocio.
En este caso se trata de un sistema de gestin interna del negocio,

principalmente orientado al rea logstica pero fcilmente adaptable y
ampliable a otros campos de la organizacin, cmo gestin de personal,
tesorera, relacin con los proveedores o clientes, etc.
De este modo este tipo de software se hace imprescindible en cualquier

empresa a da de hoy en mayor o menor medida. La informatizacin de los
datos y procesos relacionados al negocio o a la propia gestin interna es la
tendencia en un mundo donde el acceso a un ordenador y a Internet cada vez es
ms generalizado o completamente implantado en la mayora de pases
desarrollados.
Por otra parte para el desarrollo de la aplicacin se ha optado por seguir

metodologas giles de desarrollo de software, especialmente Scrum.
Actualmente las metodologas giles son una tendencia en auge frente a
mtodos ms tradicionales.
Todas las metodologas que se consideran giles cumplen con el

manifiesto gil que no es ms que una serie de principios que se agrupan en 4
valores:
9|Pgina
1. Los individuos y su interaccin, por encima de los procesos y las
herramientas.
2. El software que funciona, frente a la documentacin exhaustiva.
3. La colaboracin con el cliente, por encima de la negociacin

contractual.
4. La respuesta al cambio, por encima del seguimiento de un plan.
Con estas premisas el objetivo es incrementar la eficiencia de las

personas involucradas en el proyecto, minimizando el conste de ste.
Especialmente se pueden encontrar beneficios en las metodologas

giles frente a las clsicas en proyectos nuevos y desconocidos, es decir,
proyectos en los cuales se carece de la experiencia de desarrollos similares o
iguales, lo que implica innovar y adentrarse en lo desconocido. Y en este punto
es donde la flexibilidad que aportan las metodologas giles junto a la
participacin del cliente a la hora de decidir los cauces que toma el desarrollo
proporciona un marco muy ventajoso al proyecto, facilitando el xito y
moderando los costes.
Motivaciones
La motivacin que ha impulsado la eleccin y desarrollo de este
proyecto ha sido las ganas de aplicar diferentes conocimientos adquiridos
durante el transcurso de la carrera en las diferentes asignaturas cursadas,
especialmente las asignaturas propias de la especialidad elegida: Sistemas de
Informacin. Adems se tuvo en cuenta la experiencia profesional en el campo
de los ERPs para aprovechar el conocimiento de estos sistemas desde dentro.
Por otra parte el auge del uso de metodologas giles en el desarrollo de

software gracias a las ventajas que proporcionan frente a mtodos clsicos es la
causa de la eleccin de Scrum cmo referente en la forma que se ha
desarrollado el proyecto.
10 | P g i n a
Objetivo
El objetivo que persigue este proyecto es el desarrollo de una aplicacin

de escritorio que se encargue de la gestin logstica y econmica para
profesionales autnomos o pequeas empresas.
Adems se aprovechar la oportunidad para poner en prctica la

metodologa Scrum, basndose principalmente en este modelo para el
desarrollo de la aplicacin.
El sistema a desarrollar buscar facilitar el tratamiento y

almacenamiento de los datos relevantes del negocio, permitiendo de forma
sencilla la introduccin de los datos en el sistema y la elaboracin de informes
utilizando la informacin disponible.
De esta manera se optimizarn los procesos empresariales permitiendo

el acceso a toda la informacin de forma precisa, confiable y asegurando la
integridad de los datos. Adems posibilita la oportunidad de compartir la
informacin entre los miembros de la organizacin de diferentes
departamentos, sedes, etc.
Este objetivo se subdivide en una seria de subobjetivos que son:
- Utilizacin de una metodologa gil de desarrollo: se busca

aprovechar las ventajas que ofrecen este tipo de metodologas en el
desarrollo, aprovechando su flexibilidad.
- Desarrollo de una aplicacin utilizable por el usuario medio: con

este objetivo se busca que cualquier empleado de la empresa pueda
hacer uso del sistema sin necesidad de ser un usuario experto.
- Modularidad: la aplicacin en si ser una sola, pero debe tener sus

funciones moduladas para facilitar tanto su mantenimiento como
cualquier posible evolutivo.
- Persistencia de la informacin: los datos introducidos en el sistema

deben ser persistentes entre sesiones y usuarios.
11 | P g i n a
Estructura
El documento se divide en una serie de captulos que a su vez se

subdividen en apartados. Los captulos son los siguientes:
1. Introduccin: da una visin global del proyecto, exponiendo los

objetivos a alcanzar, l porque de la realizacin de este proyecto y el
contexto.
2. Estado del arte: expone el contexto tecnolgico que rodea al

proyecto, detallando diferentes opciones disponibles e introduciendo
al lector a las principales ofertas que existen en el mercado en
relacin al proyecto.
3. Anlisis del sistema: es un estudio previo al desarrollo en el cual se

detalla las propiedades del sistema y los elementos que se deben
desarrollar.
4. Desarrollo del sistema: en este captulo se detalla todo lo relativo al

propio desarrollo del proyecto.
5. Planificacin y presupuesto: se expone la planificacin previa basada

en las estimaciones para la duracin del proyecto y se realiza un
pequeo anlisis econmico de ste para hallar el coste final de su
realizacin.
6. Conclusiones: ltimo captulo del documento en el cual se plasman

las conclusiones extradas despus de la finalizacin del proyecto,
tanto personales como de resultados. Tambin se proponen
desarrollos futuros que enriquezcan al sistema.
12 | P g i n a
Captulo 2: Estado del arte
En este apartado se presentarn las tecnologas y metodologas
relacionadas con el proyecto de este documento. El fin de ello es acercar al
lector a estos conceptos y al contexto que rodea al proyecto en s. De forma que
pueda comprender con ms facilidad el resto del documento.
El proyecto est basado en el desarrollo de un pequeo sistema de

gestin de empresas empleado metodologas giles, y por ello en este captulo
se hablar de lo que es un sistema de planificacin de recursos empresariales
(ERP, por sus siglas en ingls, enterprise resource planning). Y en que consiste la
metodologa gil Scrum.
Aplicaciones de gestin empresarial
ERP
Los sistemas ERP son sistemas grandes y modulares de informacin que

engloban los diferentes procesos de las empresas, como ventas, produccin,
logstica, y finanzas. ERP tiene dos importantes caractersticas: facilitan una
conexin causal entre el modelo de visin de los procesos del negocio y la
implementacin de los mismos, y en segundo lugar, aseguran un nivel de
integracin, integridad de datos y seguridad, lo que no es muy sencillo de
conseguir con mltiples plataformas software. Las dos primeras etapas del ciclo
de vida de ERP son la planificacin y seleccin del paquete. Una vez que se han
completado estas fases, comienza la etapa de implementacin y normalmente
tiene una duracin mayor que las otras dos fases anteriores juntas. Esta etapa
puede durar meses o incluso aos, por lo que es bastante importante y el xito
de ERP viene determinado por esta etapa y la eleccin de cmo abordar la
implementacin. Hay una variacin en los rangos de fracaso para la
implementacin de ERP, que subyace en la propia definicin de fracaso. Donde
un autor define fracaso cuando se ha terminado el proyecto completo, otro
autor puede definirlo cuando no se han cumplido los objetivos por tiempo y/o
presupuesto.
Hay diferentes metodologas de implementacin pero las dos

aproximaciones ms usuales son:
13 | P g i n a
Implementacin Big Bang.
Implementacin gil.
Tal como se indica en el inicio de este documento, para este desarrollo

se emplear la metodologa Scrum que ms adelante se detallar su
funcionamiento.
No obstante, en este mismo captulo se explicar brevemente estas dos

implementaciones.
Ciclo de vida
EL ciclo de vida de un ERP consiste en 4 etapas como se puede observar

en la Figura 1. En ella se puede observar las dos primeras etapas (planificacin y
seleccin del paquete) y las dos ltimas etapas, que son implementacin y
mantenimiento. La fase de planificacin es en la que los gerentes del proyecto
se deben cuestionar la necesidad para un nuevo sistema ERP, a la vez que
seleccionan la aproximacin general del sistema de informacin que mejor se
adecuar a los desafos crticos de la empresa y que mejorar la estrategia
organizativa. Esta fase de decisin incluye la definicin de los requisitos del
sistema, los objetivos y beneficios. La fase de la seleccin del paquete consiste
en la seleccin del producto que mejor se adece a los requisitos de la
organizacin. Se analizan factores como el precio, la experiencia y los servicios
de mantenimiento y se define el acuerdo contractual, pero tambin es
importante realizar un anlisis del retorno de la inversin del producto
seleccionado. En la fase de implementacin, se elige la estrategia de
implementacin, personalizacin y adaptacin del paquete ERP adquirido de
acuerdo a las necesidades de la organizacin. Una vez que se ha implementado
el sistema, se debe hacer una labor de mantenimiento porque se deben corregir
los fallos y realizar mejoras generales a los sistemas.
Ilustracin 1 - ERP Ciclo de vida
14 | P g i n a
Aproximaciones en la implementacin de ERP
Es muy importante tener en cuenta que la instalacin y la

implementacin son dos conceptos completamente distintos. La instalacin es
el mecanismo de cambiar de un paquete software a otro, teniendo siempre la
mnima cantidad de errores. La implementacin es un mtodo que usa una
empresa para lograr sus objetivos cambiando la forma en la que llevan a cabo
sus operaciones.
La implementacin garantiza no solo que se ha instalado el software,

sino que tambin cumple el objetivo operacional y estratgico. Una instalacin
con xito no asegura que el sistema ERP logre las metas de la empresa durante
un periodo de tiempo prolongado.
El xito de ERP reside en la eleccin de la implementacin y tambin en

los costes y riesgos de la implementacin del proyecto, que es dependiente del
tipo de implementacin elegido por la organizacin. Las dos aproximaciones de
implementacin ms usuales son Big Bang y la gil, como se coment
anteriormente. En la Big Bang, se divide el proceso de implementacin en dos
fases distintas que se ejecutan en un orden estricto, sin la posibilidad de volver
a una fase anterior, ya que es muy caro rehacer los cambios de ERP para la
empresa. Por lo tanto, la aproximacin Big Bang tambin es conocida como el
modelo en cascada. Por otro lado, la metodologa gil, es iterativa e incremental
por naturaleza, centrndose en enviar el conjunto completo funcional mediante
pequeos trozos a lo largo de ciclos cortos. La aproximacin gil tambin se
conoce como aproximacin por fases o incremental.
Implementacin Big Bang
Con esta implementacin el cambio entre usar el sistema heredado y el

nuevo sistema es la llamada transicin de sistema.
Todo el mundo comienza a usar el sistema nuevo en la misma fecha y a

partir de ese momento no se usar de nuevo el antiguo sistema. La adopcin de
esta implementacin es muy arriesgada porque hay muy pocas posibilidades de
incorporar aprendizaje de este nuevo sistema. Una vez que la gerencia decide
utilizar el mtodo Big Bang y apoya los cambios necesarios para implementarlo,
comienza el verdadero proceso de cambio. En este proceso existen varios pasos:
preparacin de la gerencia, conversin del sistema, lanzamiento de partes del
sistema ERP y facilitar la enseanza necesaria para los futuros usuarios. Ya
15 | P g i n a
realizados los pasos anteriores, se apagar el sistema antiguo, y entonces, se
podr cargar y lanzar el sistema ERP [4].
Una vez que se lanza el ERP nuevo ya no hay vuelta atrs. Despus de
introducir el ERP, normalmente hay cada inicial del sistema, que ocurre porque
los usuarios estn pelendose con el nuevo ERP y a su vez con la conexin entre
el sistema y su trabajo cotidiano. Lo que se puede observar en la Figura 2, es
que despus de la lnea roja, que representa el big bang, el rendimiento
organizativo tiene un valor inferior, que permanecer un tiempo ah, y despus
se volver a incrementar su valor.
Ilustracin 2 - Rendimiento del sistema
Se tiene que considerar este periodo de alcance, de forma que seamos

capaces de tratar con estos problemas y dificultades. El proceso total de la
implementacin para los ERP de tipo big bang se muestra en la Figura 3.
16 | P g i n a
Ilustracin 3 - Proceso de implantacin de Big Bang
Este modelo consta de partes separadas, partiendo de la preparacin de

la gestin y las actividades involucradas (las cajas grises de la figura), al paso que
se tiene que dar una vez que se ha llegado a un acuerdo. Este ltimo paso
consiste en la conversin del sistema con todas las subactividades incluidas y los
resultados de las mismas, representados justo a la derecha de las cajas grises de
la imagen. El informe de la gestin del sistema permite una mejor organizacin.
Una vez que se ha convertido el sistema, se puede comenzar a lanzar partes del
sistema (tercera caja gris de la figura), y despus el siguiente paso (la ltima caja
gris) es la preparacin del usuario, que lo lleva a cabo el departamento de
recursos humanos. Como resultado se obtendr una lista de usuario expertos en
el nuevo sistema. Mientras se ensea a los usuarios, se realiza un informe con
esta instruccin de los usuarios, la cual se necesitar para la implementacin
final del sistema ERP.
17 | P g i n a
Implementacin gil
La implementacin gil se realiza de una forma incremental o por fases.

El principal compromiso de la implementacin de la metodologa gil es evitar
los obstculos y problemas asociados a la implementacin big bang. La
metodologa gil se basa en la simplicidad, en entregar las funcionalidades
operativas del software lo ms rpido posible, empezando por los componentes
ms importantes del negocio [1]. La implementacin gil consiste en dos fases:
anlisis y realizacin de Sprint como se muestra en la Figura 4.
A continuacin se van a explicar ambas fases detenidamente. [2]
Anlisis
Esta fase consiste en 4 pasos:
1. Preparacin del proyecto durante el cual se definen los

diferentes elementos, tales como labores,
18 | P g i n a
responsabilidades, estndares para la documentacin y
requisitos del hardware.
2. Proceso de visualizacin en el que se identifican

cuidadosamente todos los procesos operativos y procesos
que dependen de condiciones especficas, como seguridad,
autorizaciones e interfaces. Estos resultados sern la base
para la construccin de unos cimientos slidos para el
proyecto entero.
3. Funcionamiento de referencia del sistema, el cual se basar

en el software de ERP.
4. Fase de evaluacin. En esta fase, se determina la prioridad

de los requisitos adicionales y las funcionalidades, en orden
del valor del negocio. Despus de esto, el equipo de
implementacin estima el esfuerzo que ser necesario para
realizar esto y determina la planificacin de los sprints para
que se suministren los componentes del sistema.
Realizacin del Sprint
Esta fase consiste en los 5 siguientes pasos [3]:
1. Reuniones de planificacin al comienzo de cada sprint. Se

define el objetivo del sprint entre el propietario y el equipo
de implementacin.
2. Realizacin de los requisitos, de pruebas y documentacin.
3. Reuniones diarias del estado del proyecto. En esta fase se

registra el estado del proyecto y se discuten los diversos
obstculos que el equipo ha podido encontrar.
4. Sesin de prueba del Sprint. Durante esta fase los usuarios y

el equipo IT determinan si los procesos cumplen los
requisitos.
19 | P g i n a
5. Se llevar a cabo una revisin del Sprint para comprobar
que se puede mejorar en los futuros sprints.
Productos existentes
Actualmente en el mercado existen muchas opciones de ERP, desde

grandes sistemas para grandes clientes, hasta software libre destinado a
pequeas empresas, pasando por aplicaciones desarrolladas a medida del
cliente. Entre todas estas alternativas se pueden destacar los siguientes
productos por su relevancia [5]:
20 | P g i n a
- SAP R/3 o All in One:
Es actualmente el sistema de mayor xito del mercado, es la solucin

integrada de la empresa SAP. Se encuentra dividida por mdulos segn su rea
de negocio y pudindose implantar por separado. Adems de los mdulos que
forman el estndar del sistema, ofrece enormes posibilidades de desarrollos
propios para hacer la solucin ms adaptada a los requerimientos de cada
cliente. Se trata de un sistema integrado, por lo cual la informacin que utiliza
se guarda de manera centralizada para todo el sistema, permitiendo as el
manejo de la informacin en empresas de gran tamao [6].
o Pros: mayor oferta de preconfiguraciones para diferentes

verticales de la industria, velocidad de implantacin,
escalabilidad, mayor cuota de mercado.
o Contras: perfil de implementacin de mayor riesgo, tiene el

coste ms elevado, mayor tiempo de amortizacin.
- Oracle ERP:
Oracle ofrece una gran cantidad de opciones de ERP. E-Business Suite

12.1 abarca todas las facetas de la ERP y todas las industrias. La ltima versin
incluye una cartera integrada de herramientas de inteligencia empresarial.
Tambin ofrece suites completas de ERP de las empresas adquiridas como
PeopleSoft y JD Edwards [6].
o Pros: coste ms reducido que SAP, segunda mayor cuota de

mercado, mejor adaptacin a la nube.
21 | P g i n a
o Contras: menor funcionalidad, menor escalabilidad.
- Microsoft Dynamics:
Es el producto ERP y CRM de Microsoft, la rama ERP es una familia de

productos de planificacin de recursos empresariales dirigido a las medianas
empresas as como a empresas filiales y divisiones de grandes organizaciones.
Microsoft Dynamics ERP incluye 4 principales productos: Microsoft Dynamics AX
(antiguamente Axapta), Microsoft Dynamics GP (antiguamente Great Plains
Software), Microsoft Dynamics NAV (antiguamente Navision), Microsoft
Dynamics SL (antiguamente Solomon IV) [6].
o Pros: mayor porcentaje de usuarios que ven reflejados sus

beneficios, tiene el precio ms bajo entre los tres grandes
sistemas ERP del mercado. Fcil uso. Acceso online con la
interfaz Microsoft Outlook.
o Contras: menor cuota de mercado que las alternativas, peor

adaptabilidad a la empresa que sus competidores.
22 | P g i n a
- Software Libre:
Adems de los principales productos que se han mencionado

anteriormente, tambin existen multitud de opciones en el mbito del software
libre, destacando estas opciones como muy interesantes para empresas y
usuarios como a los que va orientado este proyecto, por eso mismo es
importante destacar la existencia de estas alternativas a los grandes productos
software. Algunos ejemplos de software libre son ERPNext, Apache OFBiz,
Odoo, etc.
- Pros: permite ahorrar en la adquisicin, mantenimiento y renovacin

de tecnologas, de fcil acceso para la pequea empresa.
- Contras: menor funcionalidad, peligro de abandono por parte de la
comunidad.
Herramientas de desarrollo
En este apartado se hablar de las herramientas de desarrollo

relacionadas con el proyecto.
23 | P g i n a
Microsoft Windows 8.1
Windows 8.1 es una versin de Microsoft Windows, lnea de sistemas

operativos desarrollada por Microsoft para su uso en computadoras personales,
incluidas computadoras de escritorio en casa y de negocios, computadoras
porttiles, netbooks, tabletas, servidores y centros multimedia.
Para el proyecto a desarrollar Windows es el entorno ideal para ello, ya

que la previsin es que los equipos del cliente donde correr la aplicacin
tambin utilicen este sistema operativo, por lo que ms adelante se detallar
con que tecnologa se desarrollar el sistema, que ser toda la suite de
Microsoft, as que utilizar Windows supondr poder utilizar todos estos
programas de forma mucho ms sencilla.
Visual Studio 2013
Microsoft Visual Studio es un entorno (IDE, por sus siglas en ingls) para
sistemas operativos Windows. Soporta mltiples lenguajes de programacin
tales como C++, C#, Visual Basic .NET,F#, Java, Python, Ruby, PHP; al igual que
entornos de desarrollo web como ASP.NET MVC, Django, etc., a lo cual sumarle
las nuevas capacidades online bajo Windows Azure en forma del editor Monaco.
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 versin .NET 2002). As se pueden crear
aplicaciones que se comuniquen entre estaciones de trabajo, pginas web,
dispositivos mviles, dispositivos embebidos, consolas, etc.
En el caso del proyecto que se aqu se trata se utilizar para el desarrollo

de la aplicacin en el lenguaje C# y aprovechar la facilidad de uso de una base
de datos usando Microsoft SQL Server 2012 como se detallar en el siguiente
apartado.
24 | P g i n a
SGBD
Un sistema gestor de base de datos (SGBD) es un conjunto de programas

que permiten el almacenamiento, modificacin y extraccin de la informacin
en una base de datos, adems de proporcionar herramientas para aadir,
borrar, modificar y analizar los datos. Los usuarios pueden acceder a la
informacin usando herramientas especficas de interrogacin y de generacin
de informes, o bien mediante aplicaciones al efecto.
Estos sistemas tambin proporcionan mtodos para mantener la

integridad de los datos, para administrar el acceso de usuarios a los datos y para
recuperar la informacin si el sistema se corrompe. Permiten presentar la
informacin de la base de datos en variados formatos. La mayora incluyen un
generador de informes. Tambin pueden incluir un mdulo grfico que permita
presentar la informacin con grficos y tablas.
Hay muchos tipos distintos segn cmo manejen los datos y muchos
tamaos distintos de acuerdo a si operan en computadoras personales y con
poca memoria o grandes sistemas que funcionan en mainframes con sistemas
de almacenamiento especiales [7].
Generalmente se accede a los datos mediante lenguajes de

interrogacin, lenguajes de alto nivel que simplifican la tarea de construir las
aplicaciones. Tambin simplifican la interrogacin y la presentacin de la
informacin. Un SGBD permite controlar el acceso a los datos, asegurar su
integridad, gestionar el acceso concurrente a ellos, recuperar los datos tras un
fallo del sistema y hacer copias de seguridad. Las bases de datos y los sistemas
para su gestin son esenciales para cualquier rea de negocio, y deben ser
gestionados con esmero.
En el caso de la aplicacin desarrollada en este proyecto, el sistema

gestor de base de datos utilizado es Microsoft SQL Server 2014, que es un
sistema de manejo de bases de datos del modelo relacional, desarrollado por la
empresa Microsoft.
El lenguaje de desarrollo utilizado (por lnea de comandos o mediante la

interfaz grfica de managment studio) es Transact-SQL (TSQL), una
implementacin del estndar ANSI del lenguaje SQL, utilizado para manipular y
recuperar datos (DML), crear tablas y definir relaciones entre ellas (DDL).
25 | P g i n a
Metodologa de desarrollo
Qu es Scrum?
Scrum es una metodologa gil para el desarrollo de software o la

gestin de proyectos. Antes de la definicin de Scrum, es imprescindible
entender el concepto de gil. El desarrollo de software gil se define como [8]:
Generalmente, el desarrollo de software es una actividad catica, a

menudo se caracteriza por la frase cdigo y arreglar. El problema del
desarrollo de software reside en que el cdigo se escribe muchas veces sin
seguir un plan subyacente, y el propio diseo del sistema se improvisa a partir
de muchas decisiones a corto plazo. De hecho, esto funciona bastante bien
cuando el sistema es pequeo, pero conforme el sistema va creciendo, se va
haciendo ms difcil aadir nuevas funcionalidades. Adems, tambin se hacen
predominantes los bugs y aumenta la dificultad de arreglarlos. Para evitarlos, es
necesario una larga fase de pruebas una vez que se han definido todas las
funciones del sistema. Esta fase causa estragos en los cronogramas, ya que la
realizacin de pruebas y la depuracin es imposible de planificar.
El movimiento original de intentar cambiar esto, introdujo la nocin de

metodologa. Estas metodologas imponen un proceso disciplinado sobre el
desarrollo de software con el objetivo de elaborar un software ms predecible y
eficiente. Esto se consigue desarrollando un proceso detallado con especial
nfasis en la planificacin, inspirada en otras disciplinas de la ingeniera -
tambin llamadas metodologas de la ingeniera.
Las metodologas giles surgieron como reaccin a estas metodologas.

La atraccin que sufre mucha gente por estas metodologas viene provocada
por la burocracia que conlleva las metodologas de la ingeniera. Estos mtodos
nuevos intentan ofrecer un compromiso eficiente entre procesos,
proporcionando los procesos nicamente necesarios para lograr una
recompensa razonable. El resultado de todo esto son los significativos cambios
que sufren los mtodos giles frente a los mtodos de la ingeniera. La
diferencia ms determinante es que estas metodologas se basan en la poca
documentacin, normalmente resaltando la poca cantidad de documentos para
una tarea. Se podra decir que estn enfocadas al cdigo: siguiente una ruta que
diga que la parte principal de la documentacin es el cdigo fuente.
Las metodologas giles son flexibles ms que predictivas. Los mtodos

de la ingeniera tienden a intentar planificar detalladamente una gran parte del
26 | P g i n a
proceso del software durante un largo periodo de tiempo, lo que funciona hasta
que algo cambia. En cambio, las metodologas giles se acogen al cambio
continuo. Intentan ser procesos que se adaptan y prosperan con el propio
cambio.
Por otro lado, las metodologas giles estn ms enfocadas al ser

humano que a los procesos. El objetivo de las metodologas de la ingeniera es
definir un proceso que funcionar bien sin importar quin lo vaya a usar. En
cambio, las metodologas giles reivindican que el no usar procesos supondr el
desarrollo de las habilidades del equipo, de forma que, el papel de un proceso
es dar soporte al equipo desarrollador en su trabajo.
Actualmente hay muchas metodologas giles en uso, pero ha sido

necesario el uso de esta metodologa para el desarrollo del presente proyecto.
Por lo tanto, es imprescindible hablar de Scrum antes de meterse en la
implementacin del mismo.
A continuacin se presenta una breve descripcin de la metodologa

Scrum:
La metodologa Scrum para el desarrollo gil de software representa un

punto de partida de la gestin en cascada. De hecho, Scrum y otro tipo de
procesos giles se inspiraron en sus limitaciones. La metodologa Scrum enfatiza
en la comunicacin y colaboracin, el funcionamiento del software, y la
flexibilidad de la que dispone para adaptarse a las emergentes realidades de las
empresas - todos los atributos de los que careca el modelo de cascada.
Qu caracteriza a Scrum?
De todas las metodologas giles, Scrum es nica porque introduce la

idea del control emprico de los procesos. Esto significa que Scrum utiliza el
progreso real de un proyecto para planificar y concertar los lanzamientos. En
Scrum, los proyectos se dividen en ritmos de trabajo breves, conocidos como
sprints. Normalmente, tienen una, dos o tres semanas de duracin. Al final de
cada sprint, el cliente y los miembros del equipo se renen para evaluar el
progreso del proyecto y planear los siguientes pasos a seguir. Esto permite que
la direccin del proyecto se ajuste o se reoriente una vez finalizado el trabajo,
sin especulaciones ni predicciones [9].
27 | P g i n a
Filosficamente, este nfasis continuo de evaluar las tareas finalizadas
es el principal causante del xito que tiene esta metodologa entre los
directores y desarrolladores. Pero lo que verdaderamente permite funcionar a
la metodologa Scrum es un conjunto de papeles, responsabilidades, y
reuniones.
Los papeles de Scrum
Scrum tiene tres papeles fundamentales: Product Owner (propietario del

producto), Scrum Master (especialista en Scrum) y Team Member (miembros
del equipo) [10].
Product Owner: En Scrum, el Product Owner se encarga de comunicar la

visin del producto al equipo de desarrollo. l/ella tambin deben
representar el inters del cliente por medio de los requisitos y la
priorizacin. Como el Product Owner es el que ms autoridad tiene de los
tres papeles en Scrum, tambin es el que mayor responsabilidad recibe.
En otras palabras, el Product Owner es el individuo que tiene afrontar las
consecuencias cuando un proyecto va mal.
La autoridad y responsabilidad del Product Owner le hace difcil

conseguir el balance correcto de implicacin. Como Scrum evala la auto-
organizacin entre equipos, el Product Owner debe luchar por no supervisar
hasta el ltimo detalle. Al mismo tiempo, el Product Owner tiene que estar a la
disposicin de las preguntas del equipo.
Scrum Master: El Scrum Master acta como enlace entre el Product

Owner y el equipo. El Scrum Master no dirige al equipo. l/ella se encarga
de evitar cualquier barrera que impida al equipo lograr sus objetivos de
sprint. En resumen, este papel hace que el equipo sea creativo y
productivo, a la vez que permite que los logros del equipo sean visibles
ante el Product Owner. El Scrum Master tambin aconseja al Product
Owner sobre cmo maximizar el ROI (Return Of Investment) para el
equipo.
Team Member: En la metodologa Scrum, el equipo es el responsable de

terminar el trabajo. Idealmente, los equipos estn formados por siete
miembros multifuncionales, ms/menos dos personas. Para proyectos de
software, un equipo habitual sera una mezcla de ingenieros de software,
arquitectos, programadores, analistas, testers, y diseadores de UIs. En
28 | P g i n a
cada sprint, el equipo es responsable de determinar cmo va a lograr
acabar el trabajo. Esto garantiza al equipo un grado de autonoma, pero,
al igual que pasa con la situacin del Product Owner, esta libertad viene
acompaada por la responsabilidad de cumplir los objetivos del sprint.
La siguiente imagen muestra el flujo habitual de Scrum:
1. Diagrama sencillo del proceso:
Ilustracin 4 - Procesos Scrum
29 | P g i n a
2. Diagrama ms complejo e informativo del proceso:
Ilustracin 5 - Procesos Scrum (complejo)
30 | P g i n a
Captulo 3: Anlisis del sistema
En este apartado, la meta a conseguir es identificar los objetivos que han

de ser alcanzados para el desarrollo del sistema final. Para lograr esto se tomar
como referencia las historias de usuario que representan las necesidades que
deben cubrir las funcionalidades de la aplicacin, y de este modo satisfacer las
exigencias del cliente.
Para la realizacin del proceso de extraccin de informacin relativa a

las necesidades a cubrir se llevar a cabo entre los miembros del equipo de
desarrollo y el propio cliente. Este proceso, gracias a la metodologa Scrum, no
se limitar a la fase inicial del proyecto, como ocurrira en un desarrollo clsico
generalmente, si no que se tratar de un proceso iterativo en constante
evolucin para poder amoldarse a los requerimientos del cliente de la forma
ms eficiente.
Las historias de usuario que se extraigan de las reuniones con el cliente,

describirn una funcionalidad que debe incorporar un sistema de software, y
cuya implementacin aporta valor al cliente.
La estructura de una historia de usuario est formada por:
- Nombre breve y descriptivo.
- Descripcin de la funcionalidad en forma de dilogo o monlogo

del usuario describiendo la funcionalidad que desea realizar.
- Criterio de validacin y verificacin que determinar para

considerar terminado y aceptable por el cliente el desarrollo de la funcionalidad
descrita.
Las historias de usuario se descomponen en tareas. Estas tareas son

unidades de trabajo que tienen asignado un esfuerzo estimado y un estado. Por
31 | P g i n a
lo que es en las tareas en los que se basa la estimacin de esfuerzos general del
proyecto.
Definicin
Para la definicin del sistema, es decir, para la extraccin de la

informacin que ayude a modelar la aplicacin segn las necesidades del
cliente, se realiza una reunin entre todos los miembros interesados en el
proyecto. En dicha reunin el cliente expone su idea del sistema, que
necesidades debe cubrir y que funciones quiere que le aporte. Tambin los
miembros del equipo tcnico aportan su visin para enriquecer la definicin
final del sistema a desarrollar. Finalmente con toda la informacin extrada de la
reunin el Product Owner, el actor que representa la voz del cliente, escribe las
historias de usuario donde se representa formalmente la definicin del sistema,
adems se extraen las tareas que componen las historias de usuario, se les
asigna un coste (un esfuerzo estimado) y las prioriza. Quedando formado el
Product Backlog que ser la base del proyecto a desarrollar.
Es importante aclarar que debido a la naturaleza gil del proyecto, la

definicin inicial del sistema puede verse alterada en el transcurso del
desarrollo del mismo. Ya que como ms adelante se ver, el desarrollo se divide
en diferentes etapas o Sprints, entre los cuales se repetir la reunin entre los
miembros del proyecto, pudindose incluir, modificar o eliminar historias de
usuario y/o tareas. Por este motivo el anlisis expuesto en este captulo
nicamente se trata del anlisis inicial, y en prximos captulos se describirn los
anlisis correspondientes a la reunin de cada Sprint.
32 | P g i n a
Historias de usuario
Las historias de usuario se definirn utilizando el siguiente modelo:
Historia de
Usuario
ID HUXX
Nombre
Prioridad
Riesgo
Descripcin
Validacin
Donde cada campo tiene el siguiente significado:
- ID:
Se trata del identificador nico asignado a este elemento del
proyecto, se seguir el formato HUXX para las historias de usuario.
- Nombre:
Es nombre corto utilizado para describir muy brevemente la
historia de usuario.
- Prioridad:
Es la preferencia de cara al desarrollo de la historia de usuario
respecto a las dems.
Valores: Alta, media y baja.
- Riesgo:
Se trata de la importancia de la historia de usuario en relacin al
conjunto del proyecto. Cuantificando de este modo el dao provocado en
caso de fallo.
Valores: Alto, medio y bajo.
33 | P g i n a
- Descripcin:
Breve explicacin de las intenciones de la historia de usuario.
Debe dejar clara la idea de la propia historia.
- Validacin:
Son las condiciones que deben cumplirse una vez la historia est
completamente desarrollada para que se pueda por finalizada.
Historia de
Usuario
ID HU01
Nombre Introducir ventas realizadas.
Prioridad Media
Riesgo Bajo
Descripcin Como gestor de ventas quiero introducir las operaciones de venta de artculos
realizadas en el sistema.
Validacin - Quiero que la operacin quede registrada a nombre de un empleado.

- Quiero que la operacin se diferencie por centro y cliente.
- Quiero que cada venta de un tipo de artculo se haga por separado.
- Quiero que en la venta se almacene el precio del artculo en ese
momento.
Historia de
Usuario
ID HU02
Nombre Introducir compras realizadas.
Prioridad Media
Riesgo Bajo
Descripcin Como gestor de compras quiero introducir las operaciones de compra de

34 | P g i n a
artculos realizadas en el sistema.
Validacin - Quiero que la compra se guarde en el sistema.

- Quiero que la compra guarde una relacin de proveedor, empleado
que la realiza, el centro de destino y el precio pagado por la compra.
Historia de
Usuario
ID HU03
Nombre Registrar y administrar artculos.
Prioridad Alta
Riesgo Alto
Descripcin Como gestor de compras quiero registrar los artculos nuevos en el sistema.
Validacin - Quiero poner introducir nuevos artculos en el sistema.

- Los artculos deben agruparse por su tipologa.
- Cada artculo tiene asociado un precio de venta.
- Los datos almacenados se pueden modificar posteriormente.
Historia de
Usuario
ID HU04
Nombre Registrar y administrar proveedores.
Prioridad Alta
Riesgo Alto
Descripcin Como gestor de compras quiero registrar nuevos proveedores.
Validacin - Quiero poder introducir nuevos proveedores en el sistema.

- Cada proveedor debe tener relacionado un nombre, un NIF, un email
y una cuenta bancaria.
- Puede haber almacenados dos proveedores con el mismo NIF.
35 | P g i n a
Historia de
Usuario
ID HU05
Nombre Registrar y administrar centros.
Prioridad Alta
Riesgo Alto
Descripcin Como gestor de almacenes quiero disponer de diferentes centros como

destino / origen de las mercancas.
Validacin - Quiero poder introducir nuevos centros en el sistema.

- Cada centro debe tener relacionado un nombre, un telfono, un email
y una direccin fsica.
Historia de
Usuario
ID HU06
Nombre Control de stocks.
Prioridad Alta
Riesgo Medio
Descripcin Como gestor de almacenes quiero tener control de los stocks de los artculos
que hay en los centros.
Validacin - Quiero incluir nuevos artculos a un centro.

- Quiero aumentar o reducir la cantidad almacenada.
- Quiero poder tener el mismo artculo en varios centros.
Historia de
36 | P g i n a
Usuario
ID HU07
Nombre Apariencia de la aplicacin
Prioridad Baja
Riesgo Bajo
Descripcin Como usuario quiero que la aplicacin tenga un aspecto simple y sencillo de
manejar.
Validacin - Quiero que las ventanas sean reducidas y contengan solo la

informacin imprescindible.
- Quiero que para entrar en algn modo se abra una ventana
especfica.
- Quiero unas funciones bsicas (comprar y vender) de fcil acceso.
Historia de
Usuario
ID HU08
Nombre Funcionamiento en Windows
Prioridad Alta
Riesgo Alto
Descripcin Como usuario quiero que el sistema funcione en el sistema operativo

Windows 8.1
Validacin - Quiero que la aplicacin funcione en Windows 8.1

- Diseo de la arquitectura de la aplicacin.
Historia de
Usuario
ID HU09
Nombre Importacin / Exportacin desde Excel

Prioridad Baja
Riesgo Bajo
Descripcin Como usuario quiero introducir y extraer datos en formato Excel.
37 | P g i n a
Validacin - Quiero importar datos desde un fichero .xls.
- Quiero exportar datos a un fichero .xls.
Historia de
Usuario
ID HU10
Nombre Base de datos
Prioridad Alta
Riesgo Alto
Descripcin Como desarrollador quiero que los datos introducidos sean persistentes.
Validacin - Quiero el uso de una base de datos.

- Quiero que a la base de datos se le puedan introducir nuevos datos.
- Quiero que los datos de la base de datos se puedan modificar.
- Quiero que los datos de la base de datos se puedan eliminar.
Tareas
Las tareas que componen las historias de usuario se detallan a

continuacin siguiendo el siguiente modelo:
Tarea Txx
Historia de HUxx
Usuario
38 | P g i n a
Estado
Descripcin
Donde cada campo tiene el siguiente significado:
- Tarea:
Es el identificador nico para este elemento del proyecto. El
formato que sigue es Txx, donde las xx sern un nmero entero del 01
al 99.
- Historia de Usuario:
Toda tarea forma parte de una historia de usuario que se indica
en este campo.
- Estado:
Se trata de la fase en la que se encuentra el desarrollo de la tarea.
Valores: No iniciada, En progreso y Completada.
- Descripcin:
Una breve explicacin de la finalidad de la tarea.
Tarea T01
Historia de HU03
Usuario
Estado
Descripcin Crear interfaz con la BBDD para la tabla artculos en la capa de datos.
DArticulos.cs
Tarea T02
Historia de HU03
Usuario
Estado
Descripcin Crear NArticulos.cs en la capa de negocio.
39 | P g i n a
Tarea T03
Historia de HU03
Usuario
Estado
Descripcin Crear tabla artculos en la base de datos.
Tarea T04
Historia de HU03
Usuario
Estado
Descripcin Crear procedimientos para consulta e insercin en la tabla artculos.
Tarea T05
Historia de HU03
Usuario
Estado
Descripcin Crear tabla grupo_articulos en la base de datos.
Tarea T06
Historia de HU03
Usuario
Estado
Descripcin Crear procedimientos para consulta e insercin en la tabla grupo_artculos.
Tarea T07
Historia de HU03
Usuario
Estado
Descripcin Crear interfaz con la BBDD para la tabla artculos en la capa de datos.
DGrupo_Articulos.cs
Tarea T08
Historia de HU03
Usuario
Estado
Descripcin Crear NArticulos.cs en la capa de negocio.
40 | P g i n a
Tarea T09
Historia de HU03
Usuario
Estado
Descripcin Crear la interfaz de usuario para la gestin de la tabla artculos.
Tarea T10
Historia de HU03
Usuario
Estado
Descripcin Crear la interfaz de usuario para la gestin de la tabla grupo_artculos.
Tarea T11
Historia de HU05
Usuario
Estado
Descripcin Crear la tabla centros en la base de datos.
Tarea T12
Historia de HU05
Usuario
Estado
Descripcin Crear los procedimientos en la base de datos para las consultas, inserciones y
modificaciones en la tabla centros.
Tarea T13
Historia de HU05
Usuario
Estado
Descripcin Crear DCentros.cs en la capa de datos.
Tarea T14
Historia de HU05
Usuario
Estado
Descripcin Crear NCentros.cs en la capa de negocio.
41 | P g i n a
Tarea T15
Historia de HU05
Usuario
Estado
Descripcin Crear la interfaz de usuario para la gestin de la tabla centros.
Tarea T16
Historia de HU06
Usuario
Estado
Descripcin Crear la tabla stocks en la base de datos.
Tarea T17
Historia de HU06
Usuario
Estado
modificaciones en la tabla stocks.
Tarea T18
Historia de HU06
Usuario
Estado
Descripcin Crear DStocks.cs en la capa de datos.
Tarea T19
Historia de HU06
Usuario
Estado
Descripcin Crear NStocks.cs en la capa de negocio.
Tarea T20
Historia de HU06
Usuario
Estado
Descripcin Crear la interfaz de usuario para la gestin de la tabla stocks.
42 | P g i n a
Tarea T21
Historia de HU06
Usuario
Estado
Descripcin Controlar que no hay stocks negativos.
Tarea T22
Historia de HU07
Usuario
Estado
Descripcin Diseo de la interfaz grfica de la aplicacin.
Tarea T23
Historia de HU10
Usuario
Estado 0.5
Descripcin Determinar tablas de la base de datos.
Tarea T24
Historia de HU10
Usuario
Estado 0.5
Descripcin Diseo de relaciones entre las tablas de la base de datos.
Tarea T25
Historia de HU04
Usuario
Estado
Descripcin Crear la tabla proveedores en la base de datos.
Tarea T26
Historia de HU04
Usuario
Estado
modificaciones en la tabla proveedores.
43 | P g i n a
Tarea T27
Historia de HU04
Usuario
Estado
Descripcin Crear DProveedores.cs en la capa de datos.
Tarea T28
Historia de HU06
Usuario
Estado
Descripcin Crear NProveedores.cs en la capa de negocio.
Tarea T29
Historia de HU06
Usuario
Estado
Descripcin Crear la interfaz de usuario para la gestin de la tabla proveedores.
Tarea T30
Historia de HU01
Usuario
Estado
Descripcin Crear NVentas.cs en la capa de negocio.
Tarea T31
Historia de HU01
Usuario
Estado
Descripcin Crear la interfaz de usuario para la gestin de las ventas.
Tarea T32
Historia de HU01
Usuario
Estado
Descripcin Crear DVentas.cs en la capa de datos.
44 | P g i n a
Tarea T33
Historia de HU02
Usuario
Estado
Descripcin Crear NCompras.cs en la capa de negocio.
Tarea T34
Historia de HU02
Usuario
Estado
Descripcin Crear la interfaz de usuario para la gestin de las compras.
Tarea T35
Historia de HU02
Usuario
Estado
Descripcin Crear DCompras.cs en la capa de datos.
Tarea T36
Historia de HU02
Usuario
Estado
Descripcin Crear la interfaz de usuario para la gestin de las compras.
Tarea T37
Historia de HU09
Usuario
Estado
Descripcin Crear plantilla de Excel para cada tabla.
Tarea T38
Historia de HU09
Usuario
Estado
45 | P g i n a
Descripcin Crear DExcel.cs en la capa de datos.
Tarea T39
Historia de HU09
Usuario
Estado
Descripcin Crear la interfaz de usuario para la importacin de datos desde Excel.
Tarea T40
Historia de HU08
Usuario
Estado
Descripcin Diseo de la arquitectura del sistema
Tarea T41
Historia de HU01
Usuario
Estado
Descripcin Crear NCliente.cs en la capa de negocio.
Tarea T42
Historia de HU01
Usuario
Estado
Descripcin Crear la interfaz de usuario para la gestin de los clientes.
Tarea T43
Historia de HU01
Usuario
Estado
Descripcin Crear DClientes.cs en la capa de datos.
Tarea T44
Historia de HU01
Usuario
46 | P g i n a
Estado
Descripcin Crear la tabla clientes en la base de datos.
Tarea T45
Historia de HU01
Usuario
Estado
modificaciones en la tabla clientes.
Tarea T46
Historia de HU01
Usuario
Estado
Descripcin Crear NEmpleados.cs en la capa de negocio.
Tarea T47
Historia de HU01
Usuario
Estado
Descripcin Crear la interfaz de usuario para la gestin de los empleados.
Tarea T48
Historia de HU01
Usuario
Estado
Descripcin Crear DEmpleados.cs en la capa de datos.
Tarea T49
Historia de HU01
Usuario
Estado
Descripcin Crear la tabla empleados en la base de datos.
Tarea T50
47 | P g i n a
Historia de HU01
Usuario
Estado
modificaciones en la tabla empleados.
48 | P g i n a
Estimacin
La estimacin es el proceso mediante el cual se obtiene una previsin

del esfuerzo necesario para desarrollar las diferentes partes del proyecto. Esta
informacin ser de gran utilidad a la hora de organizar el desarrollo del
producto.
La estimacin de proyectos software es una tarea muy compleja, pero

de vital importancia en toda la etapa de desarrollo del software. Se ha de tener
en cuenta que las estimaciones realizadas nunca sern del todo precisas por la
gran cantidad de variables que afectan en su clculo. Pero, obviamente, cuanto
mejor sea la estimacin que se haga, mejor se podr maniobrar para logar
cumplir los objetivos y mejorar la rentabilidad del proyecto.
En el caso de este proyecto concreto, se est tomando como referencia

la metodologa gil Scrum. Para las metodologas giles existe una tcnica
bastante extendida para la estimacin. Se trata de la tcnica de Planning Poker.
En el siguiente apartado se describe el funcionamiento de este mtodo para
estimar.
Adems esta tcnica se puede utilizar conjuntamente a otros mtodos

como el juicio de un experto y las estadsticas de rendimiento del equipo en
proyectos similares. En caso de utilizar la combinacin de varias tcnicas habra
que asignar un peso a cada una de ellas y utilizar una frmula de este estilo,
ejemplo:
Juicio experto: 20%
Planning Poker: 40%
Estadsticas de Velocidad del equipo: 40%
El resultado final para esta historia sera: 20%(20) + 40%(15) + 40%(11) ;

es decir 14
En el caso concreto de este proyecto se utilizar nicamente Planning

Poker debido a la falta de un experto que pueda aportar su opinin y tambin a
la falta de experiencia del equipo en proyectos similares, por lo que no habra
nada en lo que basarse.
49 | P g i n a
Planning Poker
Una de las tcnicas ms extendidas para la ayuda de la estimacin de las

historias de usuario en Scrum es la conocida como Planning Poker. Este proceso
tiene como objetivo el poder realizar un clculo del esfuerzo necesario para
llevar a cabo las distintas historias de usuario mediante un consenso entre los
miembros encargados de realizar las distintas tareas que componen cada fase.
La tcnica consiste en que cada miembro del equipo elige una carta de la
baraja que representa el valor estimado del esfuerzo que l considera para la
tarea sin mostrrsela al resto de los miembros del equipo para no influenciar su
decisin. Cuando todos los miembros del equipo han elegido su carta, la
muestran al resto para as elegir la estimacin final segn la mayora. En caso de
discrepancias muy altas se puede realizar un pequeo debate para ver los
puntos de discordia y llegar a un acuerdo. Los valores de la baraja suelen ser la
secuencia de Fibonacci, con alguna pequea variacin, por lo que no es una
sucesin lineal, de esta forma se refleja la incertidumbre a la hora de realizar las
estimaciones, a mayor grado de complejidad, mayor es esta incertidumbre.
Esta tcnica sirve como se ha mencionado anteriormente para la

estimacin de historias de usuario, es decir el conjunto de todas las tareas de
que la componen, en lugar de estimar cada tarea de forma individualizada.
Ambas tcnicas son aceptables y cuentan con numerosos seguidores, pero en el
caso de este proyecto se ha optado por la estimacin de historias de usuario
completas frente a la estimacin de tareas, puesto que se ha considerado esta
como la forma ms ptima de realizar el proceso de estimacin. Un estudio
realizado [11] encontr que las estimaciones obtenidas mediante el proceso de
Planificacin de pker son menos optimistas y ms precisa que las estimaciones
obtenidas a travs de la combinacin mecnica de las estimaciones individuales
en las mismas tareas.
Estimacin en el proyecto
En este apartado se explicar la forma que se estimar este proyecto

despus del anlisis para la extraccin de las historias de usuario y sus tareas.
El mtodo que se va a utilizar estar basado en el Planning Poker

anteriormente explicado, pero adaptado a las condiciones especiales de este
proyecto. Esta adaptacin ser lo que se detalle en este captulo.
50 | P g i n a
Para realizar la estimacin de las historias de usuario se utilizar la
tcnica de Planning Poker al inicio de cada iteracin (sprint), en donde se
aplicar a todas las historias de usuario restantes. De este modo se ordenarn
por prioridad y se obtendr como resultado la cantidad de trabajo que se llevar
a cabo durante ese sprint.
Hay que tener en cuenta que el prototipo resultante de una iteracin

debe ser funcional en medida de sus posibilidades, por lo que a la hora de
asignar las historias de usuario a realizar en el sprint siempre debe ser inferior la
suma de tiempos estimados que el tiempo total de la iteracin. As, en un
principio se evitara que quedase una historia a medio hacer afectando al
funcionamiento del prototipo.
Para priorizar las historias de usuario, al principio del proyecto, y a

intervalos regulares durante el proyecto, se va estimando el esfuerzo de cada
una en puntos de usuario. Normalmente se utilizan los nmeros 0, 1, 3, 5, 8, 13,
20, 40 y 100 como puntos de usuario. 0 indica una historia con esfuerzo
prcticamente nulo, mientras que una con 100, indica que el esfuerzo es
extremo y que incluso no es asumible ahora mismo. El Product Owner expone
cada una de las historias y el equipo intenta llegar a un consenso con el esfuerzo
asignado. Se suelen utilizar otras historias para comparar. Estos valores sern
los utilizados en este proyecto.
Un ejemplo de funcionamiento y de formato de las tablas de estimacin

utilizando Planning Poker es la siguiente, que adems ser el utilizado durante
el desarrollo del presente proyecto.
Historia de Miembro Estimacin Prioridad

Usuario A B C media
HU01 13 20 13 15,33333333 Baja
HU02 13 13 20 15,33333333 Alta
HU03 5 8 8 7 Media
En la tabla del Planning Poker podemos observar las valoraciones de

cada miembro del equipo que se ha supuesto para el desarrollo del proyecto. Se
observa como han utilizado valores para las horas de la serie 0, 1, 3, 5, 8, 13, 20,
40 y 100. De este modo lo primero sera establecer la capacidad de trabajo del
51 | P g i n a
equipo durante una iteracin. Para este ejemplo se va a suponer una capacidad
de trabajo de 20 horas.
La solucin sera rellenar ese espacio disponible de 20 horas con las

historias de usuario por completar, teniendo en cuenta lo prioritario de cada
una de estas, por lo que se deben coger primero las de prioridad alta, despus
prioridad media y por ltimo prioridad baja.
Segn el ejemplo anterior en este primer sprint se llevara a cabo la

historia de usuario 2, que tiene una estimacin de 15,3 horas, puesto que la
siguiente historia de usuario no tendra cabida en este sprint.
El tiempo que existe de diferencia entre el estimado y el total de la

iteracin puede utilizarse para solventar los normales errores de estimacin,
permitiendo recuperar posibles retrasos en el desarrollo debidos a cualquier
causa. Lo importante es que al finalizar el sprint el resultado sea un prototipo
funcional que pueda ser presentado al cliente.
52 | P g i n a
Captulo 4: Desarrollo del sistema
En este captulo se realizar el seguimiento del desarrollo del proyecto,

desde el fin del anlisis hasta completar todas las historias de usuario detalladas
en este anlisis del sistema.
Se va a distribuir en varias partes. Primeramente una visin global del

desarrollo, donde se explicar las tecnologas utilizadas y el motivo de su
eleccin. Luego se detallar cada fase del desarrollo, llamada Sprint. En total se
contar con seis Sprint de dos semanas cada uno. Ms adelante en el apartado
de los Sprint se describir y explicar con ms detalle el funcionamiento y
composicin de stos.
Visin general
Para el desarrollo del sistema se ha seleccionado una combinacin de

tecnologas y metodologas que incluyen las explicadas en el captulo de Estado
del arte. En ese captulo se exponen diferentes posibilidades en algunos casos
como el lenguaje o las herramientas de desarrollo del proyecto. La metodologa
a utilizar est ya predeterminada por la naturaleza del proyecto, siendo
imprescindible el empleo de Scrum por este motivo.
La combinacin elegida para el desarrollo es:
- Plataforma .NET
o Microsoft Visual Studio 2013.
o Lenguaje C#.
o Microsoft SQL Server 2014.
En la historia de usuario HU08 se pide que la aplicacin debe funcionar

en Windows, por lo que de entre las opciones disponibles, se ha considerado
que esta combinacin de productos Microsoft es la ms ptima.
Las ventajas de esta configuracin son la fiabilidad de una aplicacin

desarrollada en esta plataforma para Windows, las facilidades que proporciona
53 | P g i n a
Visual Studio para el desarrollo de una interfaz sencilla y a la vez bien integrada
en el sistema operativo Windows.
Otro beneficio de dicha combinacin es la sencilla conexin con la base

de datos.
Arquitectura
El modelo de arquitectura que se ha seleccionado para el desarrollo de

la aplicacin del proyecto est basado en un modelo Cliente Servidor.
Cliente - Servidor
Es un modelo para construir sistemas de informacin, que se sustenta en

la idea de repartir el tratamiento de la informacin y los datos por todo el
sistema informtico, permitiendo mejorar el rendimiento del sistema global de
informacin. A continuacin se muestra una ilustracin de este sistema:
Ilustracin 6 - Cliente-Servidor
54 | P g i n a
En el caso de este proyecto, en el lado del servidor reside toda la
informacin de la base de datos, adems de que es donde corre el sistema
gestor de la base de datos (SGDB), en este caso Microsoft SQL Server 2014.
Por otra parte se encuentra el lado del cliente, el cual sera la aplicacin
que utiliza el usuario para introducir, modificar o visualizar los datos
almacenados en el sistema.
MVC
La aplicacin del lado del cliente, se ha estructurado siguiendo el patrn

Modelo-Vista-Controlador (MVC).
El modelovistacontrolador (MVC) es un patrn de arquitectura de

software que separa los datos y la lgica de negocio de una aplicacin de la
interfaz de usuario y el mdulo encargado de gestionar los eventos y las
comunicaciones. Para ello MVC propone la construccin de tres componentes
distintos que son el modelo, la vista y el controlador, es decir, por un lado
define componentes para la representacin de la informacin, y por otro lado
para la interaccin del usuario. Este patrn de arquitectura de software se basa
en las ideas de reutilizacin de cdigo y la separacin de conceptos,
caractersticas que buscan facilitar la tarea de desarrollo de aplicaciones y su
posterior mantenimiento [12].
De manera genrica, los componentes de MVC se podran definir como

sigue:
- Modelo: Es la representacin de la informacin con la cual el sistema

opera, por lo tanto gestiona todos los accesos a dicha informacin, tanto
consultas como actualizaciones, implementando tambin los privilegios
de acceso que se hayan descrito en las especificaciones de la aplicacin
(lgica de negocio). Enva a la 'vista' aquella parte de la informacin que
en cada momento se le solicita para que sea mostrada (tpicamente a un
usuario). Las peticiones de acceso o manipulacin de informacin llegan
al 'modelo' a travs del 'controlador'.
- Controlador: Responde a eventos (usualmente acciones del usuario) e

invoca peticiones al 'modelo' cuando se hace alguna solicitud sobre la
55 | P g i n a
informacin (por ejemplo, editar un documento o un registro en una
base de datos). Tambin puede enviar comandos a su 'vista' asociada si
se solicita un cambio en la forma en que se presenta el 'modelo' (por
ejemplo, desplazamiento o scroll por un documento o por los diferentes
registros de una base de datos), por tanto se podra decir que el
'controlador' hace de intermediario entre la 'vista' y el 'modelo'.
- Vista: Presenta el 'modelo' (informacin y lgica de negocio) en un

formato adecuado para interactuar (usualmente la interfaz de usuario)
por tanto requiere de dicho 'modelo' la informacin que debe
representar como salida.
Ilustracin 7 - MVC
Aunque se pueden encontrar diferentes implementaciones de MVC, el

flujo de control que se sigue generalmente es el siguiente:
1. El usuario interacta con la interfaz de usuario de alguna forma (por

ejemplo, el usuario pulsa un botn, enlace, etc.)
2. El controlador recibe (por parte de los objetos de la interfaz-vista) la

notificacin de la accin solicitada por el usuario. El controlador gestiona
el evento que llega, frecuentemente a travs de un gestor de eventos
(handler) o callback.
56 | P g i n a
3. El controlador accede al modelo, actualizndolo, posiblemente
modificndolo de forma adecuada a la accin solicitada por el usuario
(por ejemplo, el controlador actualiza el carro de la compra del usuario).
Los controladores complejos estn a menudo estructurados usando
un patrn de comando que encapsula las acciones y simplifica su
extensin.
4. El controlador delega a los objetos de la vista la tarea de desplegar la

interfaz de usuario. La vista obtiene sus datos del modelo para generar la
interfaz apropiada para el usuario donde se reflejan los cambios en el
modelo (por ejemplo, produce un listado del contenido del inventario). El
modelo no debe tener conocimiento directo sobre la vista. Sin embargo,
se podra utilizar el patrn Observador para proveer cierta indireccin
entre el modelo y la vista, permitiendo al modelo notificar a los
interesados de cualquier cambio. Un objeto vista puede registrarse con el
modelo y esperar a los cambios, pero aun as el modelo en s mismo sigue
sin saber nada de la vista. Este uso del patrn Observador no es posible
en las aplicaciones Web puesto que las clases de la vista estn
desconectadas del modelo y del controlador. En general el controlador
no pasa objetos de dominio (el modelo) a la vista aunque puede dar la
orden a la vista para que se actualice. Nota: En algunas
implementaciones la vista no tiene acceso directo al modelo, dejando que
el controlador enve los datos del modelo a la vista, por ejemplo en el
proyecto que se desarrolla.
5. La interfaz de usuario espera nuevas interacciones del usuario,

comenzando el ciclo nuevamente.
En la aplicacin que se desarrolla en este proyecto el patrn modelo

vista controlador, junto a la base de datos en el lado del servidor, quedara
estructurado de la siguiente forma que se muestra en el diagrama:
Capa Capa Capa SGBD

Vista Negocio Datos (Servidor)
Ilustracin 8 - Capas
57 | P g i n a
Empezando desde el nivel superior, tenemos la vista, que se
corresponde con la capa con su mismo nombre, Capa Vista. En esta capa se
implementar todo lo relacionado con la interfaz de usuario, siendo esta la
nica con la que el usuario podr interactuar directamente. Por otra parte la
capa Vista interactuar con la Capa Negocio para obtener e insertar datos en el
sistema.
Despus se dispone de la Capa Negocio, que es la correspondiente al

controlador del patrn MVC. En la capa Negocio se gestionar el
funcionamiento del sistema. Esta capa conecta por un lado con la capa Vista y
por el otro con la capa de Datos.
La ltima capa correspondiente al patrn MVC es la capa Datos, que

representa al Modelo. Esta capa se encarga de recibir la informacin desde la
base de datos y transformarla en formato til para manejar desde la aplicacin,
y del mismo modo acta en el sentido contrario, ajustar los datos
proporcionados por la capa Negocio para ser insertados en la base de datos.
Por ltimo se dispone del lado servidor, en el cual se sita el sistema

gestor de base de datos, Microsoft SQL Server 2014 en este caso. En el captulo
propio se explica que es un SGBD y cul es su funcin.
Como dato importante cabe resaltar que las consultas a la base de datos
se realizarn mediante procedimientos. En el siguiente apartado se detallar
este punto.
Capa Datos
Para la conexin de la capa de datos entre el cliente y el servidor se

utilizarn procedimientos almacenados en la base de datos para la realizacin
de consultas en esta.
Un procedimiento almacenado [13] de SQL Server es un grupo de una o

varias instrucciones Transact-SQL o una referencia a un mtodo de Common
Runtime Language (CLR) de Microsoft .NET Framework. Los procedimientos se
asemejan a las construcciones de otros lenguajes de programacin, porque
pueden:
- Aceptar parmetros de entrada y devolver varios valores en forma de

parmetros de salida al programa que realiza la llamada.
58 | P g i n a
- Contener instrucciones de programacin que realicen operaciones en la
base de datos. Entre otras, pueden contener llamadas a otros
procedimientos.
- Devolver un valor de estado a un programa que realiza una llamada para
indicar si la operacin se ha realizado correctamente o se han producido
errores, y el motivo de estos.
Ventajas de usar procedimientos almacenados
En la siguiente lista se describen algunas de las ventajas que brinda el

uso de procedimientos.
- Trfico de red reducido entre el cliente y el servidor.
Los comandos de un procedimiento se ejecutan en un nico lote de

cdigo. Esto puede reducir significativamente el trfico de red entre el servidor
y el cliente porque nicamente se enva a travs de la red la llamada que va a
ejecutar el procedimiento. Sin la encapsulacin de cdigo que proporciona un
procedimiento, cada una de las lneas de cdigo tendra que enviarse a travs
de la red.
- Mayor seguridad:
o Varios usuarios y programas cliente pueden realizar operaciones

en los objetos de base de datos subyacentes a travs de un
procedimiento, aunque los usuarios y los programas no tengan
permisos directos sobre esos objetos subyacentes. El
procedimiento controla qu procesos y actividades se llevan a
cabo y protege los objetos de base de datos subyacentes. Esto
elimina la necesidad de conceder permisos en cada nivel de
objetos y simplifica los niveles de seguridad.
o La clusula EXECUTE AS puede especificarse en la instruccin

CREATE PROCEDURE para habilitar la suplantacin de otro usuario
o para permitir que los usuarios o las aplicaciones puedan realizar
ciertas actividades en la base de datos sin necesidad de contar con
permisos directos sobre los objetos y comandos subyacentes. Por
ejemplo, algunas acciones como TRUNCATE TABLE no tienen
59 | P g i n a
permisos que se puedan conceder. Para poder ejecutar TRUNCATE
TABLE, el usuario debe tener permisos ALTER en la tabla
especificada. Puede que la concesin de permisos ALTER a un
usuario en una tabla no sea lo ideal, pues en realidad el usuario
tendr permisos muy superiores a la posibilidad de truncar una
tabla. Si se incorpora la instruccin TRUNCATE TABLE en un
mdulo y se especifica la ejecucin del mdulo como un usuario
con permisos para modificar la tabla, se pueden ampliar los
permisos para truncar la tabla al usuario al que se concedan
permisos EXECUTE para el mdulo.
o Al llamar a un procedimiento a travs de la red, solo est visible la

llamada que va a ejecutar el procedimiento. Por lo tanto, los
usuarios malintencionados no pueden ver los nombres de los
objetos de base de datos y tabla, incrustados en sus propias
instrucciones Transact-SQL, ni buscar datos crticos.
o El uso de parmetros de procedimientos ayuda a protegerse

contra ataques por inyeccin de cdigo SQL.Dado que la entrada
de parmetros se trata como un valor literal y no como cdigo
ejecutable, resulta ms difcil para un atacante insertar un
comando en la instruccin Transact-SQL del procedimiento y
comprometer la seguridad.
- Reutilizacin del cdigo
El cdigo de cualquier operacin de base de datos redundante resulta un

candidato perfecto para la encapsulacin de procedimientos. De este modo, se
elimina la necesidad de escribir de nuevo el mismo cdigo, se reducen las
inconsistencias de cdigo y se permite que cualquier usuario o aplicacin que
cuente con los permisos necesarios pueda acceder al cdigo y ejecutarlo.
- Mantenimiento ms sencillo
Cuando las aplicaciones cliente llaman a procedimientos y mantienen las

operaciones de base de datos en la capa de datos, solo deben actualizarse los
cambios de los procesos en la base de datos subyacente. El nivel de aplicacin
permanece independiente y no tiene que tener conocimiento sobre los cambios
realizados en los diseos, las relaciones o los procesos de la base de datos.
60 | P g i n a
- Rendimiento mejorado
De forma predeterminada, un procedimiento se compila la primera vez

que se ejecuta y crea un plan de ejecucin que vuelve a usarse en posteriores
ejecuciones. Como el procesador de consultas no tiene que crear un nuevo plan,
normalmente necesita menos tiempo para procesar el procedimiento.
Si ha habido cambios importantes en las tablas o datos a los que se hace

referencia en el procedimiento, el plan precompilado podra hacer que el
procedimiento se ejecutara con mayor lentitud. En este caso, volver a crear el
procedimiento y forzar un nuevo plan de ejecucin puede mejorar el
rendimiento.
Tipos de procedimientos almacenados
- Definidos por el usuario
Un procedimiento definido por el usuario se puede crear en una base de

datos definida por el usuario o en todas las bases de datos del sistema excepto
en la base de datos Resource. El procedimiento se puede desarrollar en
Transact-SQL o como una referencia a un mtodo de Common Runtime
Language (CLR) de Microsoft .NET Framework.
- Temporales
Los procedimientos temporales son una forma de procedimientos

definidos por el usuario. Los procedimientos temporales son iguales que los
procedimientos permanentes salvo porque se almacenan en tempdb. Hay dos
tipos de procedimientos temporales: locales y globales.Se diferencian entre s
por los nombres, la visibilidad y la disponibilidad. Los procedimientos
temporales locales tienen como primer carcter de sus nombres un solo signo
de nmero (#); solo son visibles en la conexin actual del usuario y se eliminan
cuando se cierra la conexin. Los procedimientos temporales globales
presentan dos signos de nmero (##) antes del nombre; son visibles para
cualquier usuario despus de su creacin y se eliminan al final de la ltima
sesin en la que se usa el procedimiento.
61 | P g i n a
- Sistema
Los procedimientos del sistema se incluyen con SQL Server. Estn

almacenados fsicamente en la base de datos interna y oculta Resource y se
muestran de forma lgica en el esquema sys de cada base de datos definida por
el sistema y por el usuario. Adems, la base de datos msdb tambin contiene
procedimientos almacenados del sistema en el esquema dbo que se usan para
programar alertas y trabajos. Dado que los procedimientos del sistema
empiezan con el prefijo sp_, le recomendamos que no use este prefijo cuando
asigne un nombre a los procedimientos definidos por el usuario. Para obtener
una lista completa de los procedimientos del sistema, vea Procedimientos
almacenados del sistema (Transact-SQL).
SQL Server admite los procedimientos del sistema que proporcionan una
interfaz de SQL Server a los programas externos para varias actividades de
mantenimiento. Estos procedimientos extendidos usan el prefijo xp_.Para
obtener una lista completa de los procedimientos extendidos, vea
Procedimientos almacenados extendidos generales (Transact-SQL).
- Extendidos definidos por el usuario
Los procedimientos extendidos permiten crear rutinas externas en un

lenguaje de programacin como C.Estos procedimientos son archivos DLL que
una instancia de SQL Server puede cargar y ejecutar dinmicamente.
62 | P g i n a
Sprints
En Scrum un proyecto se ejecuta en bloques temporales cortos y fijos

(iteraciones de un mes natural y hasta de dos semanas). Cada iteracin tiene
que proporcionar un resultado completo, un incremento de producto que sea
potencialmente entregable, de manera que cuando el cliente (Product Owner)
lo solicite slo sea necesario un esfuerzo mnimo para que el producto est
disponible para ser utilizado. Para ello, durante la iteracin el equipo colabora
estrechamente y se llevan a cabo las siguientes dinmicas:
- Cada da el equipo realiza una reunin de sincronizacin, donde cada

miembro inspecciona el trabajo de los otros para poder hacer las
adaptaciones necesarias, comunica cuales son los impedimentos con que
se encuentra, actualiza el estado de la lista de tareas de la iteracin
(Sprint Backlog) y los grficos de trabajo pendiente (Burndown charts).
- El Facilitador (Scrum Master) se encarga de que el equipo pueda cumplir
con su compromiso y de que no se merme su productividad.
o Elimina los obstculos que el equipo no puede resolver por s

mismo.
o Protege al equipo de interrupciones externas que puedan afectar
su compromiso o su productividad.
Tambin existen una serie de restricciones que deben ser tenidas en

consideracin:
- No se puede cambiar los objetivos/requisitos de la iteracin en curso:
o En la reunin de planificacin de la iteracin el equipo adquiri el

compromiso de completar en la iteracin unos requisitos
concretos, bas su plan y organizacin en ellos. Cambiar los
objetivos/requisitos de la iteracin dificulta la concentracin del
equipo, baja su moral y su compromiso.
o El hecho de no poder cambiar los objetivos/requisitos de la

iteracin una vez iniciada facilita que el cliente cumpla con su
responsabilidad de conocer qu es lo ms prioritario a desarrollar,
antes de iniciar la iteracin.
o Notar que Scrum minimiza esta necesidad ya que, por un lado, los
objetivos/requisitos que se estn desarrollando eran los ms
63 | P g i n a
prioritarios justo antes de iniciar la iteracin y, por otro lado, las
iteraciones en Scrum son suficientemente cortas (2 o 4 semanas)
como para que la probabilidad de cambios una vez iniciada la
iteracin sea mnima.
- Terminacin anormal de la iteracin:
o Slo en situaciones muy excepcionales el cliente o el equipo

pueden solicitar una terminacin anormal de la iteracin. Esto
puede suceder si, por ejemplo, el contexto del proyecto ha
cambiado enormemente y no es posible esperar al final de la
iteracin para aplicar cambios, o si el equipo encuentra que es
imposible cumplir con el compromiso adquirido. En ese caso, se
dar por finalizada la iteracin y se dar inicio a otra mediante una
reunin de planificacin de la iteracin.
Sprint Planning
La planificacin de las tareas a realizar en la iteracin se divide en dos

partes:
- Primera parte de la reunin. Se realiza en un timebox de cmo mximo 4

horas *(aproximadamente):
o El cliente presenta al equipo la lista de requisitos priorizada del

producto o proyecto, pone nombre a la meta de la iteracin (de
manera que ayude a tomar decisiones durante su ejecucin) y
propone los requisitos ms prioritarios a desarrollar en ella.
o El equipo examina la lista, pregunta al cliente las dudas que le

surgen, aade ms condiciones de satisfaccin y selecciona los
objetivos/requisitos ms prioritarios que se compromete a
completar en la iteracin, de manera que puedan ser entregados
si el cliente lo solicita.
64 | P g i n a
- Segunda parte de la reunin. Se realiza en un timebox de cmo mximo 4
horas*. El equipo planifica la iteracin, elabora la tctica que le permitir
conseguir el mejor resultado posible con el mnimo esfuerzo. Esta
actividad la realiza el equipo dado que ha adquirido un compromiso, es el
responsable de organizar su trabajo y es quien mejor conoce cmo
realizarlo.
o Define las tareas necesarias para poder completar cada

objetivo/requisito, creando la lista de tareas de la iteracin (Sprint
Backlog) basndose en la definicin de completado.
o Realiza una estimacin conjunta del esfuerzo necesario para

realizar cada tarea.
o Cada miembro del equipo se autoasigna a las tareas que puede

realizar.
Sprint 0
Se conoce como Sprint 0 a la fase inicial del proyecto donde se dedica

aproximadamente una semana, independientemente del formato, duracin,
etc, del resto de sprints. En este Sprint es donde se va a preparar el equipo
tanto tecnolgicamente como metodolgicamente para que el desarrollo del
proyecto tenga un buen comienzo, en especial en casos en los que se desconoce
la metodologa o no se tiene mucha prctica con ella.
El objetivo del Sprint 0 es preparar el conjunto del proyecto desde una

perspectiva:
- Tecnolgica.
- Metodolgica.
- Organizativa para que el desarrollo del proyecto tenga un buen

comienzo y mejor finalizacin.
65 | P g i n a
Todo ello consiste bsicamente en:
- Definir con el cliente. En primer lugar "the product owner", es decir, yo

misma en este caso me estoy ocupando de definir con el cliente las
caractersticas y funcionalidades del proyecto con el mayor nmero de detalles
posibles. Con toda esa informacin construyo un documento en forma de
historias de usuarios.
- Construir el Product Backlog. Las historias de usuario presentan

unidades que pueden presentarse a los clientes como elementos acabados. Con
ellas construimos el "Product Backlog".
- Reuniones de equipo. Se realiza una reunin con el equipo donde se

presentan las historias de usuario y donde el equipo deber: identificar lagunas
de informacin, dificultades tcnicas, dependencias entre historias, proponer
creacin/divisin de historias de usuario...
Los motivos para hacerlo de este modo, son que nos aporta las
siguientes ventajas, siendo stas de gran ayuda en el desarrollo del proyecto,
mejorando la productividad del equipo.
- Obtenemos una definicin contrastada con el cliente en forma de

historias de usuarios.
- El equipo participa en la preparacin del desarrollo identificando

necesidades, dificultades, ventajas...
- La preparacin de cada sprint ser ms fcil de realizar porque el

equipo conoce con detalle el proyecto.
El Sprint 0 de este proyecto se podra identificar perfectamente con la

fase de anlisis descrita en captulos anteriores de este documento.
Adems de eso en el sprint se define la capacidad de trabajo del equipo

por cada iteracin. Para ello se han de definir el tamao de la iteracin y el
rendimiento del equipo:
Tamao del Sprint 2 Semanas (10 das laborables).
66 | P g i n a
Trabajo por da 4 horas.
Horas por sprint 40 horas.
En este caso la cantidad de horas es relativamente baja para una

iteracin puesto que, aunque se simule la existencia de otros miembros en el
equipo para estimaciones, reuniones, etc., debido a la naturaleza del proyecto
el trabajo es realizado realmente por una nica persona.
De esta forma para todo lo relacionado con el desarrollo en s de la

aplicacin siempre se tendr en consideracin esta limitacin. No siendo as
para situaciones que puedan ser simuladas de forma sencilla y que den al
proyecto un aspecto ms real y natural [14].
Primer Sprint
Lo primero que se hace en la iteracin es poner sobre la mesa el Product

Backlog conseguido y utilizarlo para estimar. El mostrado aqu es una versin
resumida de las historias de usuario presentadas en el captulo de anlisis.
Historia de Miembro Estimacin

Prioridad
Usuario A B C media
HU01 20 20 40 26,66666667 Media
HU02 20 20 40 26,66666667 Media
HU03 13 13 20 15,33333333 Alta
HU04 13 13 20 15,33333333 Alta
HU05 13 13 20 15,33333333 Alta
HU06 13 13 20 15,33333333 Alta
HU07 5 3 8 5,333333333 Baja
HU08 3 3 5 3,666666667 Alta
HU09 13 8 13 11,33333333 Baja
HU10 20 20 13 17,66666667 Alta
67 | P g i n a
Como se puede apreciar en la tabla varias historias tienen la misma
prioridad, alta en este caso, por lo que al presentarse esta situacin queda a
juicio del equipo seleccionar la ms prioritaria de entre ellas.
Horas mximas 40
Horas utilizadas 39
Horas restantes 1
Historia Horas estim.

HU08 3,666666667
HU10 17,66666667
HU03 17,66666667
En este caso se observa que las historias de usuario que han sido
seleccionadas para esta iteracin son las historias:
Historia de
Usuario
ID HU08
Nombre Funcionamiento en Windows
Prioridad Alta
Riesgo Alto
Descripcin Como usuario quiero que el sistema funcione en el sistema operativo

Windows 8.1
Validacin Quiero que la aplicacin funcione en Windows 8.1

Diseo de la arquitectura de la aplicacin
Historia de
Usuario
ID HU10
68 | P g i n a
Nombre Base de datos
Prioridad Alta
Riesgo Alto
Descripcin Como desarrollador quiero que los datos introducidos sean persistentes.
Validacin - Quiero el uso de una base de datos.

- Quiero que a la base de datos se le puedan introducir nuevos datos.
- Quiero que los datos de la base de datos se puedan modificar.
- Quiero que los datos de la base de datos se puedan eliminar.
Historia de
Usuario
ID HU03
Nombre Registrar y administrar artculos.
Prioridad Alta
Riesgo Alto
Descripcin Como gestor de compras quiero registrar los artculos nuevos en el sistema.
Validacin - Quiero poner introducir nuevos artculos en el sistema.

- Los artculos deben agruparse por su tipologa.
- Cada artculo tiene asociado un precio de venta.
En primer lugar lo que se ha realizado es la historia de usuario nmero

ocho, ya que en parte se encuentra hecha en el anlisis. En cualquier caso no
hay que confundir la parte del anlisis con la que hay que hacer en el desarrollo.
En el anlisis se eligi una arquitectura y una configuracin en base a esta
historia de usuario, pero en este apartado lo que se va a hacer es poner en
prctica los puntos establecidos anteriormente.
Se crea el proyecto en Visual Studio 2013, y se le nombra tfg01. A partir

de ah se estructura en capas siguiendo el patrn modelo vista controlador.
69 | P g i n a
Se genera la solucin tfg01, y dentro de este se crean los proyectos
diferenciando las capas: Datos, Negocio y Vista.
Ilustracin 9 - Capas desarrollo
Despus, para la historia de usuario 10 (HU10), que se centra en la

creacin de la base de datos, se genera una base de datos en el SGBD SQL
Server:
Ilustracin 10 - Base de datos
70 | P g i n a
Para la creacin de la base de datos lo primero es crear un servidor
dentro del SGBD, en este caso se crea PC.
Dentro de PC, en las bases de datos del sistema se crea la que se

utilizar para este proyecto en concreto: db01.
Se trata de una base de datos relacional clsica.
De esta manera quedara creada la base de datos para el desarrollo del

sistema. Estando disponible en todo momento la posibilidad de aadir tablas o
datos, as como eliminarlas o modificarlas en cualquier momento.
En este momento ya se tiene preparada la base de datos vaca en

nuestro SGBD y es hora de disear esta misma. Para ello se determina la
necesidad de las siguientes tablas:
- Artculo.
- Centro.
- Cliente.
- Compra.
- Empleado.
- Grupo de artculos.
- Proveedor.
- Stock.
- Venta.
Para el diseo completo se diferenciarn tres fases que ayudarn en el

momento del desarrollo por sprints, teniendo as en cada iteracin un esquema
de las tablas a utilizar.
71 | P g i n a
Primera fase:
Ilustracin 11 - Modelo base datos I
72 | P g i n a
Segunda fase:
Ilustracin 12 - Modelo base de datos II
73 | P g i n a
Tercera fase:
venta compra proveedor

id_venta id_compra id_proveedor
id_cliente id_proveedor nombre
id_empleado id_empleado apellidos
id_articulo id_articulo nif
cantidad cantidad telefono
precio_unidad precio_unidad email
id_centro id_centro direccion
fecha fecha cuenta_bancaria
cliente
id_cliente
nombre
apellidos empleado
nif id_empleado
telefono nombre
email apellidos
direccion id_centro
email
telefono
articulo
id_articulo
centro
nombre id_centro
descripcion nombre
id_grupo_articulos telefono
precio_venta email
direccion
grupo_articulos
id_grupo_articulos
nombre
descripcion stock
id_articulo
id_centro
cantidad
Ilustracin 13 - Modelo base de datos III
Con este proceso el diseo de la base de datos quedara listo y se podra

pasar al siguiente punto del desarrollo.
74 | P g i n a
El siguiente paso ser abordar la HU03. En esta historia de usuario se
pide la gestin de artculos. Para ello ser necesario abordar la gestin de los
grupos de artculos ya que los artculos tienen dependencia de esto.
El primer paso ser la creacin de los procedimientos almacenados:
- Buscar en grupo_artculos:
Ilustracin 14 - Procedimiento buscar
- Insertar en grupo_artculos:
Ilustracin 15 - Procedimiento insertar
- Eliminar de grupo_artculos:
75 | P g i n a
Ilustracin 16 - Procedimiento eliminar
- Mostar contenido de grupo_artculos:
Ilustracin 17 - Procedimiento mostrar
- Editar elemento de grupo_artculos:
Ilustracin 18 - Procedimiento editar
76 | P g i n a
Con estos procedimientos almacenados quedara completa la gestin
(consulta, insercin, eliminacin o modificacin) de los registros de la tabla de
grupo_artculos en la parte del SGBD.
El siguiente paso es crear la conexin a la base de datos desde el

programa cliente. Para ello se abre el Visual Studio 2013 se crea una nueva
solucin de Windows Forms, se crean las tres capas anteriormente cometnadas
dentro de la solucin a modo de proyectos independientes, se les asignan las
dependencias entre ellos siguiendo las relaciones mencionadas en el apartado
Ilustracin 19 - Conexin base de datos
MCV y se crea la clase conexin dentro de la capa de datos del programa:
Siendo Cn la conexin a la base de datos alojada en el servidor

especificado en la ruta.
En este momento ya se dispone de una base de datos y la conexin a

esta desde la aplicacin. El siguiente paso a dar es la creacin en la capa de
datos de la clase DGrupo_articulos, que se encargar de ser la interfaz entre la
base de datos y el resto de la aplicacin.
Este esta clase resumida resultante:
namespace CapaDatos
{
public class DGrupo_articulos
{
private int _Id_grupo_articulos;
private string _Nombre;
private string _Descripcion;
77 | P g i n a
private string _TextoBuscar;
//Insertar
public string Insertar(DGrupo_articulos Grupo)
{
Introduce los datos en los parmetros del procedimiento de la
base de datos y hace la llamada a este para su ejecucin e insertar los
datos.
//Editar
public string Editar(DGrupo_articulos Grupo)
{
Introduce los datos en los parmetros del procedimiento de la
base de datos y hace la llamada a este para su ejecucin y editar as el
registro indicado.
//Eliminar
public string Eliminar(DGrupo_articulos Grupo)
{
Introduce los datos en los parmetros del procedimiento de la base

de datos y hace la llamada a este para su ejecucin y eliminar el registro
indicado.
//Mostrar
public DataTable Mostrar()
{
Devuelve todos los registros de la tabla.
//Buscar por nombre

public DataTable BuscarNombre(DGrupo_articulos Grupo)
{
Devuelve el registro con el nombre indicado.
Una vez ya se dispone de la interfaz con la base de datos el siguiente

paso es el desarrollo de la capa negocio. En la cual se incluye la clase
NGrupo_articulos. Esta clase sirve de interfaz entre la capa de datos y la interfaz
78 | P g i n a
de usuario alojada en la capa vista. Adems se encarga de la lgica de la
aplicacin y de realizar cualquier operacin que fuese necesaria.
namespace CapaNegocio
{
public class NGrupo_articulos
{
//Mtodo Insertar -> llama al insertar de DGrupo_articulos
public static string Insertar (string nombre, string descripcion)
//Mtodo Editar -> llama al editar de DGrupo_articulos

public static string Editar(int idgrupo_articulos, string nombre, string
descripcion)
//Mtodo Eliminar -> llama al eliminar de DGrupo_articulos

public static string Eliminar(int idgrupo_articulos)
//Mtodo Mostrar -> llama al mostrar de DGrupo_articulos

public static DataTable Mostrar()
//Mtodo Buscarpornombre -> llama al BuscarNombre de DGrupo_articulos

public static DataTable BuscarNombre(string nombre)
Por ltimo se ha de desarrollar la interfaz grfica para que el usuario

pueda administrar e interactuar con la aplicacin de forma amigable. Para ello
se genera la capa vista y se crea la clase Frm_Grupo_articulos.
El diseo de la interfaz de usuario quedara de la siguiente manera:
79 | P g i n a
Ilustracin 20 - Interfaz de usuario Grupo de artculos
Finalizadas las tareas para administrar los grupos de artculos se procede

a realizar los pasos equivalentes con la tabla artculos. Los pasos a dar son
similares a los mostrados con grupo de artculos.
80 | P g i n a
Ilustracin 21 - Interfaz de usuario Artculos
Con esto finalizaran las tareas del primer sprint. Como resumen del
Sprint 1 se podra decir que se ha dejado la base para continuar el desarrollo de
la aplicacin aadiendo todas las funcionalidades necesarias al sistema para
completar las historias de usuario establecidas.
81 | P g i n a
Tarea Historia de Usuario Estado inicial Estado estimado Estado final
T01 HU03 No iniciada Completada Completada
T11 HU05 No iniciada No iniciada No iniciada
Finalmente el esfuerzo dedicado al primer sprint se recoge en la siguiente

tabla:
82 | P g i n a
Historia de Tiempo Tiempo
usuario estimado final
HU08 3,666666667 3
HU10 17,66666667 16,5
HU03 17,66666667 20
Total 39 39,5
- Pruebas funcionales:
Id P0101
Resultado Vlido
Sistema Cliente
Descripcin Comprobacin que el cliente funciona en Windows.
Acciones 1. Iniciar la aplicacin en el sistema operativo Windows.
Id P0102
Resultado Vlido
Sistema Base de datos
Descripcin Mediante el SGBD insertar un registro en la tabla grupo de artculos.
Acciones 1. Iniciar el SGBD.

2. Introducir un registro en la tabla grupo_artculos.
3. Realizar una consulta del contenido de la tabla
grupo_artculos.
Id P0103
Resultado Vlido
Descripcin Mediante el SGBD insertar un registro en la tabla artculos.
83 | P g i n a
2. Introducir un registro en la tabla artculos.
3. Realizar una consulta del contenido de la tabla artculos.
Id P0104
Resultado Vlido
Sistema Cliente / Base de datos
Descripcin Comprobacin que la conexin entre ambos sistemas funciona

correctamente.

2. Insertar un registro en la tabla artculos.
3. Iniciar la aplicacin cliente.
4. Abrir la ventana de artculos.
5. Realizar una consulta del contenido de la tabla artculos.
Segundo Sprint
En este segundo Sprint se afrontarn las tareas relacionadas con los las
siguientes historias de usuario en orden de prioridad. Adems se reestiman los
esfuerzos necesarios en base a la experiencia adquirida durante el primer
Sprint:

Usuario A B C media
HU01 20 20 40 26,66666667 Media
HU02 20 20 40 26,66666667 Media
HU03 13 20 20 17,66666667 Alta
HU04 13 8 13 11,33333333 Alta
HU05 13 8 13 11,33333333 Alta
HU06 13 13 20 15,33333333 Alta
84 | P g i n a
HU07 5 3 8 5,333333333 Baja
HU08 3 3 5 3,666666667 Alta
HU09 13 8 13 11,33333333 Baja
HU10 20 20 13 17,66666667 Alta
Tal como se observa en la tabla las historias de usuario que se adjudican

a esta iteracin son las siguientes:
Horas
mximas 40
Horas
utilizadas 38
Horas
restantes 2
Horas
Historia estim.
HU04 11,33333
HU05 11,33333
HU06 15,33333
Los detalles de las historias de usuario seleccionadas se muestran en

estas tablas:
Historia de
Usuario
ID HU04
Nombre Registrar y administrar proveedores.
Prioridad Alta
Riesgo Alto
Descripcin Como gestor de compras quiero registrar nuevos proveedores.
Validacin - Quiero poder introducir nuevos proveedores en el sistema.

- Cada proveedor debe tener relacionado un nombre, un NIF, un email
y una cuenta bancaria.
- Puede haber almacenados dos proveedores con el mismo NIF.
85 | P g i n a
Historia de
Usuario
ID HU05
Nombre Registrar y administrar centros.
Prioridad Alta
Riesgo Alto
Descripcin Como gestor de almacenes quiero disponer de diferentes centros como

destino / origen de las mercancas.
Validacin - Quiero poder introducir nuevos centros en el sistema.

- Cada centro debe tener relacionado un nombre, un telfono, un email
y una direccin fsica.
Historia de
Usuario
ID HU06
Nombre Control de stocks.
Prioridad Alta
Riesgo Medio
Descripcin Como gestor de almacenes quiero tener control de los stocks de los artculos
que hay en los centros.
Validacin - Quiero incluir nuevos artculos a un centro.

- Quiero aumentar o reducir la cantidad almacenada.
- Quiero poder tener el mismo artculo en varios centros.
86 | P g i n a
El desarrollo de este sprint debido a que las tareas a realizar son de una
ejecucin similar a la desarrollada y explicada en el primer sprint con la
implementacin de los grupos de artculos, no se va a desarrollar al completo
sino que se har una simulacin.
A continuacin se muestran las interfaces de usuario de cada una de las

historias de usuario:
Ilustracin 22 - Interfaz de usuario Proveedores
87 | P g i n a
En esta imagen se muestra la interfaz para la gestin de proveedores,
que sigue la misma lnea de diseo que la anteriormente mostrada de artculos.
Despus se repite el proceso con la historia de usuario 5, en la cual se

han de hacer los desarrollos equivalentes pero partiendo de la tabla centros de
la base de datos:
88 | P g i n a
Ilustracin 23 - Interfaz de usuario Centros
89 | P g i n a
Finalmente lo ltimo a realizar en esta iteracin ser la historia de
usuario 6, en la cual hay que crear lo necesario para administrar los stocks. En
parte este desarrollo es muy similar a los anteriores, especialmente en la capa
de datos. Pero en la capa negocio se debe controlar los stocks, es decir, no
permitir que se queden en negativo ya que eso no sera posible.
Ilustracin 24 - Interfaz de usuario Stocks
Por ltimo se muestra la interfaz de usuario para administrar los stocks

directamente:
90 | P g i n a
El resumen de las tareas relacionadas con el Sprint 2 quedara de la
siguiente forma:

T01 HU03 Completada Completada Completada
91 | P g i n a
Resumen de esfuerzo dedicado a cada historia de usuario desarrollada:

HU04 11,33333 11
HU05 11,33333 10
HU06 15,33333 16
Total 38 37
- Pruebas funcionales:
Id P0201
Resultado Vlido
Descripcin Mediante el SGBD insertar un registro en la tabla proveedores.

5. Introducir un registro en la tabla proveedores.
6. Realizar una consulta del contenido de la tabla proveedores.
Id P0202
Resultado Vlido
92 | P g i n a
Descripcin Mediante el SGBD insertar un registro en la tabla centros.

8. Introducir un registro en la tabla centros.
9. Realizar una consulta del contenido de la tabla centros.
Id P0203
Resultado Vlido
Descripcin Comprobar que un artculo se puede encontrar en diferentes centros.
Acciones 1. Iniciar el SGBD

2. Introducir un registro en la tabla stocks con centro = 1.
3. Introducir otro registro usando un artculo diferente usando
centro = 2.
Id P0204
Resultado Vlido
Descripcin Comprobar que se insertan correctamente registros desde las

interfaces de usuario.
Acciones 1. Iniciar SGBD
2. Iniciar cliente -> Centros.
3. Insertar un registro.
4. Realizar una consulta de la tabla
Tercer Sprint
Las siguientes historias de usuario a realizar en esta iteracin son las

siguientes despus de reestimar y ordenarlas por prioridad:
93 | P g i n a
Usuario A B C media
HU01 40 40 40 40 Media
HU02 20 20 20 20 Media
HU03 13 20 20 17,66666667 Alta
HU04 13 8 13 11,33333333 Alta
HU05 13 8 13 11,33333333 Alta
HU06 13 13 20 15,33333333 Alta
HU07 5 3 8 5,333333333 Baja
HU08 3 3 5 3,666666667 Alta
HU09 13 8 13 11,33333333 Baja
HU10 20 20 13 17,66666667 Alta
Segn la tabla de historias de usuario la siguiente a realizar seran las

HU01 y HU02. Debido a que la HU02 tiene cierta dependencia de la HU01 se
decide que esta ser la que se lleve a cabo durante esta iteracin:
Horas
mximas 40
Horas
utilizadas 40
Horas
restantes 0
Horas
Historia estim.
HU01 40
Los detalles de esta historia de usuario son los siguientes:
Historia de
Usuario
ID HU01
Nombre Introducir ventas realizadas.
Prioridad Media
Riesgo Bajo
Descripcin Como gestor de ventas quiero introducir las operaciones de venta de artculos
realizadas en el sistema.
94 | P g i n a
Validacin - Quiero que la operacin quede registrada a nombre de un empleado.
- Quiero que la operacin se diferencie por centro y cliente.
- Quiero que cada venta de un tipo de artculo se haga por separado.
- Quiero que en la venta se almacene el precio del artculo en ese
momento.
En este sprint se tiene que desarrollar la funcionalidad de registrar

ventas, es decir, registrar ventas realizadas por un empleado a un cliente. Estas
ventas son de un artculo del cual se indica la cantidad vendida del producto.
Para poder realizar todas estas operaciones reclamadas en la historia de

usuario 1 se deben crear las tablas de empleado, cliente y venta en la base de
datos. Adems dentro del SGBD tambin hay que crear los procedimientos
necesarios para las modificaciones del contenido de las tablas.
Despus hay que completar la capa de Datos en la aplicacin. Se crean

las clases DClientes.cs, DEmpleados.cs y DVentas.cs para interactuar con la base
de datos. Estas clases tendrn los mtodos correspondientes para hacer uso de
los procedimientos almacenados en el SGBD para el manejo de los datos.
A continuacin se crean en la capa de negocio las clases NCLientes.cs,

NEmpleados.cs y NVentas.cs. En este caso las clases de empleados y clientes van
a funcionar de forma similar a lo desarrollado hasta el momento, en la capa
negocio simplemente se conectan las capas de datos y vista de la misma tabla.
Pero con la clase NVentas.cs el funcionamiento cambia ligeramente de una
forma en la cual esta clase adems de usar funciones de la clase
correspondiente de ventas de la capa de datos, tambin utiliza funciones de
otras tablas, ya que al realizar una venta se modifican los stocks disponibles.
95 | P g i n a
Finalmente se desarrollan las clases de la capa vista que incluyen las
interfaces de usuario para la administracin de estas tres tablas.
Ilustracin 25 - Interfaz de usuario Ventas
96 | P g i n a
Ilustracin 26 - Interfaz de usuario Empleados
97 | P g i n a
Ilustracin 27 - Interfaz de usuario Clientes
Finalmente se expone el estado resultante de las tareas pertenecientes

al proyecto:

98 | P g i n a
99 | P g i n a
Y el resumen de esfuerzo dedicado a la iteracin:

HU01 40 37,5
Total 40 37,5
- Pruebas Funcionales:
Id P0301
Resultado Vlido
Descripcin Comprobar que se insertan correctamente registros al realizar una

venta.
Acciones 1. Iniciar SGBD
2. Iniciar cliente -> Ventas.
3. Insertar un registro.
4. Realizar consulta de las tablas ventas y stocks.
Id P0302
Resultado Vlido
Descripcin Comprobar que asigna correctamente el precio del producto vendido.
Acciones 1. Seleccionar un artculo de la tabla artculos y obtener su

precio.
2. Realizar la venta de ese artculo.
3. Consultar la venta realizada y comprar el precio asignado con
el precio obtenido de la tabla artculos.
100 | P g i n a
Id P0303
Resultado Vlido
Descripcin Comprobar que se puede consultar todas las ventas realizadas

anteriormente.
Acciones 1. Realizar una consulta utilizando la interfaz de usuario el botn
de buscar y no aplicando ningn parmetro.
Id P0304
Resultado Vlido
Descripcin Comprobar la correcta asignacin de la fecha al realizar una venta.
Acciones 1. Realizar una venta.

2. Realizar una consulta de la venta realizada y comprobar la
correcta asignacin de la fecha.
Cuarto Sprint
Historias de usuario restantes:

Usuario A B C media
HU01 40 40 40 40 Media
HU02 20 20 20 20 Media
HU03 13 20 20 17,66666667 Alta
HU04 13 8 13 11,33333333 Alta
HU05 13 8 13 11,33333333 Alta
101 | P g i n a
HU06 13 13 20 15,33333333 Alta
HU07 5 3 8 5,333333333 Baja
HU08 3 3 5 3,666666667 Alta
HU09 13 8 13 11,33333333 Baja
HU10 20 20 13 17,66666667 Alta
Se observa que nicamente quedan por desarrollar las historias de

usuario 2, 7 y 9.
La estimacin de la iteracin quedara de la siguiente forma:
Horas
mximas 40
Horas
utilizadas 36,66667
Horas
restantes 3,333333
Horas
Historia estim.
HU02 20
HU07 5,333333
HU09 11,33333
Por lo que si el esfuerzo estimado es correcto, esta debera ser la ltima

iteracin del proyecto, quedando finalizado el desarrollo planificado.
Las historias de usuario a desarrollar son las siguientes:
Historia de
Usuario
ID HU02
Nombre Introducir compras realizadas.
Prioridad Media
Riesgo Bajo
Descripcin Como gestor de compras quiero introducir las operaciones de compra de

artculos realizadas en el sistema.
102 | P g i n a
Validacin - Quiero que la compra se guarde en el sistema.
- Quiero que la compra guarde una relacin de proveedor, empleado
que la realiza, el centro de destino y el precio pagado por la compra.
Historia de
Usuario
ID HU07
Nombre Apariencia de la aplicacin
Prioridad Baja
Riesgo Bajo
Descripcin Como usuario quiero que la aplicacin tenga un aspecto simple y sencillo de
manejar.
Validacin Quiero que las ventanas sean reducidas y contengan solo la

informacin imprescindible.
Quiero que para entrar en algn modo se abra una ventana especfica
desde una ventana principal.
Quiero unas funciones bsicas (comprar y vender) de fcil acceso.
Historia de
Usuario
ID HU09
Nombre Importacin / Exportacin desde Excel.
Prioridad Baja
Riesgo Bajo
Descripcin Como usuario quiero introducir y extraer datos en formato Excel.
Validacin Quiero importar datos desde un fichero .xls.

Quiero exportar datos a un fichero .xls.
103 | P g i n a
La primera historia de usuario que se va a abarcar es la HU02 siguiendo
el orden de prioridades.
En esta historia de usuario se pide realizar un desarrollo similar al de la

HU01 ya hecho en el anterior sprint, pero en este caso basado en la tabla de
compras.
Se crea la tabla compras en la base de datos y se crean sus

procedimientos almacenados para la gestin de la tabla.
Despus se crea en la capa datos la case DCompras.cs para interactuar

con la tabla de compras de la base de datos.
Se crea en la capa de negocio la clase NCompras.cs y en la capa vista la

interfaz de usuario para administrar las compras realizadas.
Ilustracin 28 - Interfaz de usuario Compras
El siguiente paso ser realizar la historia de usuario 7, pero teniendo en

cuenta la HU09 a la hora de agregar el botn para la importacin de Excel.
104 | P g i n a
En la HU07 se narra la necesidad de disponer de una interfaz de usuario
sencilla y que adems contenga unos accesos rpidos a determinadas funciones
como comprar y vender, en este caso se ha incluido la opcin rpida de
importar, ya que se ha determinado que es el mejor lugar para situarla.
A parte de las interfaces ya desarrolladas en historias de usuario

anteriores, se ha desarrollado la ventana de inicio de la aplicacin:
Ilustracin 29 - Interfaz de usuario Inicio
En la interfaz de la ventana de inicio se cuenta con tres accesos rpidos a

las funciones que se solicitaba de comprar, vender y adems aadida de
importar desde Excel. Desde cada botn se abre una nueva ventana con la
funcionalidad correspondiente. En la parte de administracin dispone de un
ComboBox en el cual estn todas las tablas del sistema. Se selecciona la deseada
y se pincha en el botn de Ok para entrar en la ventana de administracin de
dicha tabla.
Despus se han desarrollado las ventanas de compra y venta rpida. Son

dos formularios donde el usuario elige entre las opciones del ComboBox, las
cuales son extradas de la base de datos, de modo que solo puede introducir
105 | P g i n a
datos vlidos. Para finalizar existe el botn Comprar / Vender con el cual se
podruce el insert en la base de datos. Primero llamando a la funcin de la capa
negocio, la cual se encargar de llamar a las funciones necesarias de las distintas
tablas de la capa datos (Compra, Venta y Stocks).
Ilustracin 30 - Interfaz de usuario Venta rpida
Ilustracin 31 - Interfaz de usuario Compra rpida
Finalmente se aborda la ltima historia de usuario de la iteracin y

tambin del proyecto, la historia de usuario 9. Esta historia de usuario exige
implementar una funcionalidad que permita importar y exportar datos desde
documentos Excel al sistema desarrollado.
106 | P g i n a
Lo primero que se har para este desarrollo ser agregar una nueva
referencia a la capa negocio a objetos del tipo Excel.
Ilustracin 32 - MS Excel Obj. Library
Ahora aadiendo la lnea using Excel =

Microsoft.Office.Interop.Excel; podremos crear objetos del tipo
Excel que nos permitirn interactuar con hojas existentes o crear nuevas hojas
nuevas.
La interfaz de usuario de esta funcionalidad es la siguiente:
107 | P g i n a
Ilustracin 33 - Interfaz de usuario Importar
Con todo esto quedara finalizado el cuarto sprint y el proyecto al haber

completado todas las historias de usuario. A pesar de ello se trata de un
proyecto con grandes posibilidades de ampliacin de funcionalidades de forma
relativamente sencilla y barata, en el siguiente apartado se analizaran estas
opciones de futuro.
El resumen de Sprint 4 es el siguiente:

108 | P g i n a
Y la tabla de esfuerzo final dedicado a la iteracin:

HU02 20 17
HU07 5,333333 5
HU09 11,33333 15
109 | P g i n a
Total 36,66667 37
- Pruebas Funcionales:
Id P0401
Resultado Vlido
Descripcin Mediante el SGBD insertar un registro en la tabla compras.

2. Introducir un registro en la tabla compras.
3. Realizar una consulta del contenido de la tabla compras.
Id P0402
Resultado Vlido
Descripcin Comprobar la correcta asignacin de la fecha al realizar una compra.
Acciones 1. Realizar una compra.

2. Realizar una consulta de la compra realizada y comprobar la
correcta asignacin de la fecha.
Id P0403
Resultado Vlido
Sistema Cliente
Descripcin Comprobar que todas las funcionalidades del sistema son accesibles
desde la pantalla principal.
Acciones 1. Abrir la aplicacin.
2. Entrar en Comprar.
3. Entrar en Vender.
4. Entrar en Importar.
5. Comprobar que en el ComboBox estn todas las tablas del
sistema.
110 | P g i n a
Id P0404
Resultado Vlido
Descripcin Comprobar que importa los datos desde un Excel de forma correcta.
Acciones 1. Abrir la aplicacin.

2. Pinchar en Importar Excel.
3. Poner la ruta del archivo .cls
4. Seleccionar la tabla destino.
5. Pinchar en Importar.
6. Realizar una consulta de la tabla seleccionada y comprobar la
correcta insercin de los registros.
111 | P g i n a
112 | P g i n a
Captulo 5: Planificacin y presupuesto
En este captulo se detallarn los apartados relativos a la planificacin y

los costes econmicos del proyecto.
Planificacin
La planificacin del desarrollo de cada historia de usuario se muestra en

el siguiente diagrama de Gantt
Ilustracin 34 - Diagrama de Gantt
113 | P g i n a
Presupuesto
En este apartado se detalla el presupuesto que se estima para llevar a

cabo el proyecto.
Se desglosarn los costes en funcin de su naturaleza. Inicialmente se

calcularn todas las cantidades sin aplicar el I.V.A. y finalmente se le aadir a
los resultados totales del proyecto.
Resumen de tiempo dedicado
Segn las estimaciones de esfuerzo mostradas a lo largo de este

documento se puede extraer el nmero de horas dedicadas a cada parte del
proyecto. Se utilizarn las historias de usuario como referencia para dividir el
proyecto en partes del desarrollo, adems se le aade una fase adicional
correspondiente al anlisis y estudio previo y otra fase final correspondiente a la
documentacin.
Historia de usuario o Tiempo estimado

fase del proyecto (horas)
Estudio previo y anlisis 40
HU08 3,666666667
HU10 17,66666667
HU03 17,66666667
HU04 11,33333333
HU05 11,33333333
HU06 15,33333333
HU01 40
HU02 20
HU07 5,333333333
HU09 11,33333333
Documentacin 40
Total 233,6666667
114 | P g i n a
Coste de personal
Para calcular los costes relativos al personal se deben tener en cuenta

los roles mencionados anteriormente que formaran el equipo y se calculan las
horas utilizadas por cada uno.
Empleado Papel Dedicacin (horas) Coste (hombre/ hora) Coste total
Empleado N1 Product Owner 40 50,00 2.000,00
Empleado N2 Scrum Master 71 35,00 2.485,00
Empleado N3 Team Member 123 35,00 4.305,00
Total 8.790,00
Coste de Hardware
Para el desarrollo del sistema es necesario contar con un ordenador para

el equipo, por lo que se debe adquirir uno.
% Uso Dedicacin Periodo de Coste

Elemento Coste dedicado al (meses) deprecacin imputable
proyecto (meses)
Dell Latitude
3550 Laptop 669,00 100 2 36 37,17
El coste imputable es el resultado de dividir el nmero de meses que se

emplear el equipo entre el nmero de meses de vida til que tiene
multiplicado por el uso dedicado al proyecto y el coste de adquisicin del
equipo (sin I.V.A.).
115 | P g i n a
Coste de Software
En este apartado se detalla el software utilizado para el desarrollo del

proyecto:
Elemento Coste
Office Hogar y Empresas 2013 279,00
Windows 8.1 Pro 139,00
Microsoft Visual Studio Professional
2013 609,70
Microsoft SQL Server Developer 2012 612,00
Total 1.639,70
Resumen de costes
Finalmente tras analizar los costes por partes del proyecto se suman
todos ellos y se tiene el coste total del proyecto. Despus se ha de aadir una
previsin de fondos como costes indirectos para cubrir los posibles riesgos del
proyecto y gastos imprevistos no indicados en el presupuesto. Estos costes se
establecen en un 10% del total.
Concepto Coste
Personal
8.790,00
Hardware
37,17
Software
1.639,70
Costes indirectos (10%)
1.046,69
Total sin I.V.A.
11.513,55
Total con I.V.A.
13.931,40
116 | P g i n a
Captulo 6: Conclusiones
En este apartado se va a analizar los resultados obtenidos en el desarrollo

del proyecto, as como lo experimentado durante el transcurso de este en
relacin a la metodologa empleada.
Lo primero a detallar son los resultados en cuestin de esfuerzo de

dedicado en comparacin con el esfuerzo que se ha ido estimando durante el
proyecto. A continuacin se presentan los datos estimados y los reales:
Esfuerzo Estimado Esfuerzo Real Acumulado Estimado Acumulado Real

Sprint (horas) (horas) (horas) (horas)
0 0 0 0 0
1 39 39,5 39 39,5
2 38 37 77 76,5
3 40 37,5 117 114
4 36,66666 37 153,66666 151
117 | P g i n a
Comparativa de esfuerzo real y esfuerzo estimado
180
160
4; 153,66666
4; 151
140
120
3; 117
3; 114
Horas de trabajo
100
Acumulado estimado
80 Acumulado real
2; 77
2; 76,5
60
40 1; 39
1; 39,5
20
0 0; 0
0 1 2 3 4
Sprint
Ilustracin 35 - Comparativa esfuerzos
En los grficos anteriores se puede observar como el rendimiento final ha

sido superior al estimado, aunque en general ha sido bastante aproximado. Esto
puede deberse a la propiedad adaptativa de la metodologa, ya que al permitir
reestimaciones en cada iteracin, da la posibilidad de utilizar la experiencia
actual en el mismo proyecto para afinar la estimacin ms que si hubiese que
quedarse con los valores previos al inicio del proyecto. Especialmente
beneficioso en casos en los que la experiencia del equipo en proyectos similares
sea baja y por tanto la estimacin tenga mayor margen de error.
118 | P g i n a
Respecto a los objetivos iniciales del proyecto se ha cumplido lo que se
buscaba en esencia de este trabajo:
- Utilizacin de una metodologa gil de desarrollo: se ha empleado

con xito la metodologa Scrum, por lo que se cumple con este
punto.
- Desarrollo de una aplicacin utilizable por el usuario medio: en el

diseo de las interfaces se ha buscado que fuese todo lo ms simple
posible, facilitando al usuario sin experiencia poder utilizar todas las
funcionalidades que el sistema le ofrece.
- Modularidad: tal como se detallar en el apartado dedicado a

trabajos futuros, la aplicacin est ideada para recibir actualizaciones
con nuevos mdulos que implementes nuevas funcionalidades.
- Persistencia de la informacin: se ha incluido una base de datos

donde la informacin se almacena entre sesiones y dispositivos, as
todos los registros almacenados en el sistema son persistentes.
Finalmente se puede concluir con que los objetivos marcados

inicialmente para el proyecto a desarrollar se han cumplido, por lo que puede
considerarse exitoso el proyecto.
Desarrollos futuros
El Proyecto realizado podra decirse que una de sus caractersticas

fundamentales son las posibilidades de ampliacin que tiene, ya que debido a
su naturaleza forma una base muy buena para la inclusin de nuevas
funcionalidades de manera relativamente sencilla, ya que su estructura est
ideada para facilitar la integracin de nuevos componentes.
La capacidad de crecimiento en este tipo de aplicacin es muy

importante, ya que de este modo el sistema puede adaptarse mucho mejor a las
necesidades el cliente. De modo que sea la aplicacin la que crezca hacia la
forma de trabajar de la empresa y no al revs, obligando a esta a realizar
importantes y costosas reestructuraciones en sus procesos internos.
119 | P g i n a
La idea de este sistema para la ampliacin es poder aadir nuevas
verticales de negocio completas aprovechando el ncleo ya existente a modo de
datos maestros.
Finanzas
Ventas
Compras
Ncleo
Logstica RR.HH.
Ilustracin 36 - Partes aplicacin
Otra facilidad que tiene el sistema para admitir ampliaciones es el diseo

de la interfaz de usuario basado en diferentes ventanas. Esto permite aadir
funcionalidades sin necesidad de modificar anteriores paneles a excepcin de
una pantalla de inicio desde donde se podr acceder al resto de funciones.
Entre estas opciones de futuro se podra destacar la inclusin de

funcionalidades como las siguientes:
- Mdulo de gestin financiera:
Esta ampliacin podra dotar de una capacidad al sistema de gestionar las

finanzas de la empresa de forma completa y exhaustiva. As como llevar
la contabilidad y analizar los flujos financieros de la empresa. De este
modo el departamento financiero puede gestionar de manera ms
eficiente las cuentas de la empresa, resultando especialmente
beneficioso en el caso de que cuente con varios centros.
120 | P g i n a
- Mdulo de gestin de personal:
En este mdulo se ampliara la posibilidad de gestionar a la plantilla de la

empresa, de forma que se incluira en el sistema toda la informacin
relativa a los datos de los empleados, como vacaciones, salarios,
organizacin, etc.
- Mdulo de gestin de los proveedores:
Ampliacin de la parte de compras de la aplicacin. Sirve para optimizar

todo el proceso de compras de materiales o servicios a los proveedores.
Tambin puede utilizarse para garantizar el control sobre las operaciones
de gasto que realizan los empleados aadiendo autorizadores de gasto,
presupuestos de compras a los centros, catlogos de productos
actualizables por el proveedor, etc.
- Cliente multiplataforma:
Actualmente el cliente es nicamente utilizable en un sistema operativo

Windows de escritorio, pero una opcin a futuro para mejorar la
operatividad del sistema sera el desarrollo de versiones web y
aplicaciones parar Android e iOS. De modo que el usuario pudiese
acceder al sistema en cualquier momento y en cualquier lugar, agilizando
enormemente los procesos en determinadas circunstancias.
121 | P g i n a
Conclusiones personales
Como experiencia personal, la realizacin de este Trabajo Fin de Grado

ha sido una puesta en escena de los mltiples conocimientos adquiridos
durante el resto de la carrera. Especialmente de las asignaturas
correspondientes a la especialidad cursada: Sistemas de informacin.
De esta rea de conocimiento estaba especialmente interesado en el

campo de la gestin de proyectos as como de las metodologas giles de
desarrollo, ya que ahora mismo se encuentran en auge y significa un enfoque
diferente al tradicional, aportando nuevas formas de hacer las cosas y
resultando muy interesante su aplicacin a muchos proyectos.
Por otra parte, tambin exista y existe actualmente un gran inters en el

software de gestin de empresas por mi parte. Ya que considero que
profesionalmente es un campo en el cual hay buenas posibilidades de negocio,
puesto que prcticamente toda empresa dispone de un software de este estilo,
ya sea una gran suite en una multinacional o un pequeo programa libre en una
empresa de pocos empleados, todo ello forma un buen mercado en el que
desarrollarse como profesional. Adems la experiencia adquirida en uno de
estos sistemas (SAP) por motivos de trabajo ha resultado muy inspirador y til a
la hora de adentrarse en este campo.
La aplicacin de la metodologa Scrum ha resultado muy gratificante e

interesante y me ha servido para conocer esta forma diferente de trabajar. De
esta experiencia he sacado la conclusin de que su uso puede resultar muy
beneficioso a determinados proyectos, tanto en trminos de costes como de
ayuda al desarrollador.
En definitiva, la experiencia de este TFG ha sido muy positiva, me ha

permitido acercarme de una forma ms global a un proyecto en todas sus fases,
a diferencia de las prcticas tradicionales realizadas durante la carrera que estn
enfocadas a tareas ms concretas y relacionadas con la asignatura. De este
modo considero que es una forma ideal de finalizar la carrera y empezar un
nuevo ciclo en la vida con toda la experiencia adquirida en estos aos.
122 | P g i n a
Anexo A: Manual de usuario
En este manual de usuario se explicar el manejo de la aplicacin

desarrollada, para que un usuario inexperto pueda desenvolverse sin problemas
en la aplicacin.
1. Inicio de la aplicacin.
Nada ms iniciar la aplicacin aparecer la siguiente interfaz:
En ella observamos 4 opciones diferentes:
- rea de accesos rpidos:
o Botn Comprar: sirve para acceder a la funcin de compra rpida

de la aplicacin.
123 | P g i n a
o Botn Vender: sirve para acceder a la funcin de venta rpida de la
aplicacin.
o
o Botn Importar Excel: sirve para acceder a la funcin de
seleccionar una hoja de Excel e insertar sus datos en una tabla del
sistema.
- rea de administracin:
En la pestaa seleccione la tabla en la que desea realizar modificaciones,

inserciones o eliminacin de algn registro. Con la tabla deseada seleccionada
pinche en el botn OK.
2. Compra rpida.
Cuando acceda a la opcin de compra rpida desde el men principal se

le abrir una ventana como la siguiente:
- Para comprar un artculo debe rellenar los siguientes campos:
124 | P g i n a
o Artculo: seleccione un artculo de los disponibles en el sistema en
la lista desplegable.
o Cantidad: introduzca la cantidad deseada o seleccinela en la lista

desplegable.
o Proveedor: seleccione el proveedor al que comprar el artculo en la

lista desplegable.
o Empleado: seleccione el empleado responsable de la compra en la

lista desplegable.
o Precio/Ud.: seleccione el precio por unidad que le indique el

proveedor para la compra del producto.
Finalmente, cuando tenga seleccionados todos los datos del formulario

pinche en el botn Comprar.
3. Venta rpida.
Cuando acceda a la opcin de compra rpida desde el men principal se

le abrir una ventana como la siguiente:
125 | P g i n a
- Para vender un artculo debe rellenar los siguientes campos:
o Artculo: seleccione un artculo de los disponibles en el sistema en

la lista desplegable.
o Cantidad: introduzca la cantidad deseada o seleccinela en la lista

desplegable.
o Cliente: seleccione el cliente al que vender el artculo en la lista

desplegable.
o Empleado: seleccione el empleado responsable de la venta en la

lista desplegable.
Finalmente, cuando tenga seleccionados todos los datos del formulario

pinche en el botn Vender.
4. Administracin de tablas.
Cuando acceda a administrar cualquier tabla del sistema se le abrir una

nueva ventana con la tabla seleccionada. Dentro de esta pantalla dispone de las
opciones para la gestin de la tabla.
126 | P g i n a
En la imagen se muestra la ventana de administracin de la tabla
Clientes, pero estas instrucciones son igualmente vlidas para cualquier tabla
puesto que tienen el mismo funcionamiento:
Para que el uso de los botones Editar y Borrar tengan resultado debe
estar marcada la opcin de Habilitar modificaciones.
- Botn insertar: inserta un registro con los datos introducidos en la

primera lnea de la parte de resultados.
127 | P g i n a
- Botn Editar: debe introducir un id que ya exista en el sistema y
automticamente se sustituye el registro antiguo por el nuevo
introducido.
- Botn borrar: borra el registro seleccionado de la lista de resultados.
- Botn buscar: busca el registro o los registros que coincidan con los datos
introducidos. Se puede introducir desde todos los datos hasta ninguno.
En caso de no introducir ninguno se mostrarn todos los registros de la
tabla.
128 | P g i n a
Anexo B: Bibliografa
[1]http://afalco.hol.es/papers/a_modified_agile_methodology_for_an_erp_aca
demic_project_development.pdf
[2]http://epubs.scu.edu.au/cgi/viewcontent.cgi?article=1274&context=theses
[3]http://www.niwotridge.com/PDFs/AgileMethodsforERP.PDF
[4]http://paper.ijcsns.org/07_book/201108/20110826.pdf
[5]http://www.forbes.com/sites/louiscolumbus/2013/05/12/2013-erp-market-
share-update-sap-solidifies-market-leadership/
[6]http://www.evaluandoerp.com/nota-2559-SAP-ORACLE-o-MICROSOFT.html
[7]http://www.raima.com/products/product-comparison/
[8]https://www.scrum.org/
[9]www.scrumguides.org/
[10]https://www.scrumalliance.org/
[11]K. Molokken - Ostvold y NC Haugen (K Molkken-stvold, NC Haugen (10

13 April 2007). "Combining Estimates with Planning PokerAn Empirical Study".
18th Australian Software Engineering Conference (IEEE): 34958.
doi:10.1109/ASWEC.2007.15. Retrieved 1 February 2008.)
[12]http://blog.iandavis.com/2008/12/what-are-the-benefits-of-mvc/
[13]https://msdn.microsoft.com/es-es/library/ms190782(v=SQL.120).aspx
[14] http://blog.xebia.com/2011/02/01/scrum-effective-sprint-zero/
129 | P g i n a
130 | P g i n a

TFG Aitor Urteaga Pecharroman

Cargado por

Copyright:

Formatos disponibles

TFG Aitor Urteaga Pecharroman

Cargado por

Información del documento

Descripción 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

TFG Aitor Urteaga Pecharroman

Cargado por

Copyright:

Formatos disponibles

Universidad Carlos III de Madrid

Repositorio institucional e-Archivo http://e-archivo.uc3m.es

Urteaga Pecharromn, Aitor

Descargado de e-Archivo, repositorio institucional de la Universidad Carlos III de Madrid

TRABAJO FIN DE GRADO

GRADO EN INGENIERA INFORMTICA

Madrid, Septiembre 2015

Autor: Aitor Urteaga Pecharromn.

Tutor: Javier Fernndez Muoz.

especialmente en los momentos ms difciles, momentos en los que lo ms fcil

hubiese sido rendirse pero gracias a vuestra ayuda segu adelante.

Ahora finalmente he conseguido alcanzar la meta que me propuse hace aos y

tengo que reconocer no lo habra logrado sin vuestro apoyo.

Muchas gracias a todos por estar ah.

Este proyecto describe el desarrollo de un sistema de gestin de

This project describes the development of a enterprise resource

Captulo 2: Estado del arte ....................................................................... 13

Aplicaciones de gestin empresarial .................................................... 13

Implementacin Big Bang ................................................................ 15

Implementacin gil ........................................................................ 18

Realizacin del Sprint ....................................................................... 19

Productos existentes ........................................................................ 20

Herramientas de desarrollo ................................................................. 23

Microsoft Windows 8.1 .................................................................... 24

Visual Studio 2013 ............................................................................ 24

Metodologa de desarrollo ................................................................... 26

Qu caracteriza a Scrum? ............................................................... 27

Los papeles de Scrum ....................................................................... 28

Captulo 3: Anlisis del sistema ................................................................ 31

Historias de usuario .............................................................................. 33

Planning Poker .................................................................................. 50

Estimacin en el proyecto ................................................................ 50

Captulo 4: Desarrollo del sistema ........................................................... 53

Visin general ....................................................................................... 53

Cliente - Servidor .............................................................................. 54

Capa Datos ........................................................................................ 58

Sprint Planning ................................................................................. 64

Primer Sprint .................................................................................... 67

Segundo Sprint ................................................................................. 84

Tercer Sprint ..................................................................................... 93

Cuarto Sprint .................................................................................. 101

Captulo 5: Planificacin y presupuesto ................................................. 113

Planificacin ....................................................................................... 113

Presupuesto ........................................................................................ 114

Resumen de tiempo dedicado ....................................................... 114

Coste de personal ........................................................................... 115

Coste de Hardware ......................................................................... 115

Resumen de costes ......................................................................... 116

Captulo 6: Conclusiones ........................................................................ 117

Desarrollos futuros ............................................................................. 119

Conclusiones personales .................................................................... 122

Anexo A: Manual de usuario .................................................................. 123

Anexo B: Bibliografa .............................................................................. 129

Ilustracin 1- ERP Ciclo de vida ................................................................ 14

Ilustracin 2 - Rendimiento del sistema................................................... 16

Ilustracin 3 - Proceso de implantacin de Big Bang ............................... 17

Ilustracin 4 - Procesos Scrum ................................................................. 29

Ilustracin 5 - Procesos Scrum (complejo) ............................................... 30

Ilustracin 6 - Cliente-Servidor ................................................................. 54