Desarrollo de Software Guiado por Pruebas

UNIVERSIDAD DE PAMPLONA
Ruby on Rails.
Ing. Diego Hernando Torres Valencia
Desarrollo de software guiado por pruebas:
Ruby on Rails.

1. CONTENIDO:
1. Ejecutar las pruebas de unidad y
refactorizar el código .
2. Diseñar, codificar y ejecutar las pruebas
de integración para las funciones.
3. Diseñar, codificar y ejecutar las pruebas
funcionales para la funciónes
CONTENIDO:
UNIVERSIDAD DE PAMPLONA
Sabiduría ante todo; adquiere sabiduría;
Y sobre todas tus posesiones adquiere inteligencia.
Engrandécela, y ella te engrandecerá.
Proverbios 4:7-9

DesarrollodeSoftwareguiadoporPruebasenRoR
Objetivos del curso
• Al finalizar este curso, el participante estará preparado para:
– Describir los conceptos fundamentales de pruebas de Software
– Comprender el uso de los diagramas UML en el proceso de análisis, diseño,
programación y pruebas de software
– Aplicar el lenguaje Ruby y Rails para desarrollar una aplicación web
– Diseñar e implementar pruebas de software para una aplicación web, de un
caso de estudio, para los siguientes niveles
• Nivel de pruebas de unidad
• Nivel de pruebas de integración
• Nivel de pruebas funcionales
– Desplegar la aplicación web en un servidor en la nube y poner en producción

Estructura del curso
Sesión 1: Fundamentos de pruebas de software
Sesión 2: Caso de estudio: Diseño de la aplicación
Sesión 3: Caso de estudio: Implementación de la aplicación
Sesión 4: Diseño e Implementación de Pruebas de unidad
Sesión 5: Diseño e Implementación de Pruebas de integración
Sesión 6: Diseño e Implementación de Pruebas de funcionales
Sesión 7: Despliegue de la aplicación

Requisitos del curso
• Tener un espíritu enseñable
• Estar dispuesto en aplicar mucho en poco tiempo
• Entender la oportunidad profesional
• Tener conocimientos básicos en los siguientes conceptos, lenguajes,
modelos y tecnologías
– UML
– Paradigma de diseño y programación OxO
– Patrón arquitectónico MVC
– Programación web:
• Lenguaje de programación web: PHP, Java o C#. Si es Ruby on Rails,
excelente
• Lenguaje de hipertexto: HTML o preferiblemente HAML
• CSS
• JQuery

Desarrollo de Software Guiado por Pruebas
Sesión 1:
Fundamentos Conceptuales de Pruebas

PruebasdeSoftware:TécnicasyGestiónDesarrollodeSoftwareguiadoporPruebasenRoR Introducción: Porqué TDD
(Test-Driven Development =Guiado Por Pruebas de Software) ?
• Prueba el software de manera ARTESANAL, a través de los siguientes
pasos:
– Codifique la aplicación sin planos (sin diseño)
– Ejecute la aplicación
– Ingrese datos al azar
– Seguro que la aplicación comienza a fallar
– Ahora dedique mucho tiempo depurando y probando de nuevo: Es un círculo
vicioso.
• Y obtendrás estas consecuencias:
– La calidad de la aplicación es muy baja
– El tiempo dedicado a la depuración es muy alto
– El cliente siempre estará insatisfecho
– Las pruebas no quedan documentadas
– Cada vez que se cambia el código, la probabilidad de propagación de errores
es muy alta y difícil de detectar ya que,
– Las pruebas de regresión son casi imposibles
7

PruebasdeSoftware:TécnicasyGestiónDesarrollodeSoftwareguiadoporPruebasenRoR
• Prueba el software GUIDADO POR PRUEBAS (TDD), a través de los siguientes
pasos:
– Asegúrese de entender los planos (diseño)
– Analice los casos de prueba, si existe el diseño, de lo contrario, diseñe las pruebas
– Codifique los casos de prueba
– Ejecute las pruebas. No te preocupes que todas las pruebas fallarán
– Codifique la aplicación para que pase los casos de prueba
– Ejecute de nuevo las pruebas
• Y obtendrás los siguientes beneficios:
– La calidad de la aplicación es muy alta
– El tiempo dedicado a la depuración es muy bajo
– El cliente siempre estará más satisfecho
– Las pruebas quedan documentadas
– Cada vez que se cambia el código, la probabilidad de propagación de errores es
muy alta, pero serán detectados porque,
– Las pruebas de regresión están automatizadas
8
Introducción: Porqué TDD

• Probar software no es un proceso sencillo
• Requiere conocer los procesos y productos del desarrollo de software
– Análisis
• Diagramas de casos de uso
• Diagramas de clases de requisitos
– Diseño
• Diagramas de clases persistentes
• Interfaz gráfica del usuario
• Diagramas de estado
• Diagramas de secuencia
• Pruebas de unidad, integración y sistema
– Implementación
• El código en el patrón arquitectónico MVC
• El código de las pruebas automatizadas
9
Introducción: Porqué TDD

Introducción: Porqué falla el software?
• La calidad de una aplicación de software está estrechamente ligada a la
cantidad de errores
• La mayoría de los errores del software se deben a :
– Requisitos: incompletos, incorrectos, no verificados ni validados
– Diseño arquitectónico incoherente
– Implementación sin diseño
– Pruebas
• Pobre diseño y ejecución de las pruebas
• Baja inversión de tiempo y dinero en las pruebas
• Bajo soporte automatizado durante las pruebas
• Mala gestión de las pruebas
• El personal no está debidamente capacitado en pruebas de software
– Mala comunicación
10

Introducción: Porqué falla el software?
11
Los problemas
típicos de la
comunicación
Cómo lo explicó el
cliente
Cómo lo describió el
vendedor
Cómo lo implementó
el programador
Cómo lo diseñó el
analista
Cómo lo entendió el
líder del proyecto
Qué realmente
necesitaba el cliente
Qué soporte técnico
se brindó
Cuánto se le facturó
al cliente
Qué operaciones
fueron instaladas
Cómo el proyecto fue
documentado

Pruebas de Software: Conceptos Fundamentales
12
Los conceptos
fundamentales
de las Pruebas

El concepto: Prueba de Software
• Una Prueba de Software se define como:
– “… el proceso de ejecutar un programa con la intención de encontrar
defectos”(Myers, 1979)
• “Las pruebas pueden mostrar la presencia de defectos, pero no su
ausencia”
– “… el proceso de ejercitar o evaluar, … , un sistema o uno de sus
componentes a fin de verificar que satisface los requisitos [establecidos] o
identificar las diferencias entre los resultados actuales y los esperados”
(ANSI/IEEE Standard 729, 1983)
– “Son un elemento crítico para la garantía de la calidad del software y
representan una evaluación final de las especificaciones, del diseño y de la
codificación” [Pressman, 2002]
13

El concepto: Prueba de Software
• “… el proceso de ejecutar un programa con la intención de encontrar
defectos”(Myers, 1979)
– Parten del supuesto de que todo programa contiene defectos
– Una prueba se considera exitosa si es capaz de detectar defectos
• ¿Se puede probar exhaustivamente un programa?
– Es decir, ¿se puede probar el programa con todas las combinaciones posibles
de sus datos de entrada?
• ¿Cuántas combinaciones de datos se requieren para probar la función f?
• Si un programa no se puede probar exhaustivamente, entonces
• no se puede garantizar que el programa esté 100% libre de defectos
14
f = a/(b-c)
a
fb
c

El concepto: Proceso de Prueba
• Las actividades requeridas para llevar a cabo el proceso de pruebas se
representan mediante un modelo de procesos
15
Prueba de
Unidad
Pruebas
No
Funcionales
Prueba de
Instalación
Prueba de
Aceptación
Pruebas de
Integración
Pruebas
Funcionales
Prueba de
Unidad
Prueba de
Unidad
componente
probado
sistema en
operación
componente
probado
Especificaciones
de diseño
Requisitos
de operación
Requisitos
del cliente
Requisitos
no-funcionales
Requisitos
funcionales
código
de
componentes
componentes
integrados
sistema
validado
sistema
verificado
sistema
funcionando
...
El Modelo de Procesos de
Prueba de Pfleeger (1998)

Los conceptos: Diseño, Casos y Suite de Pruebas
• Diseño de Pruebas
– Es un proceso mediante el cual se produce una
suite de casos de prueba usando una estrategia
de pruebas
• Caso de Prueba
– Es una especificación de los datos que se
requieren para ejecutar una prueba,
precondiciones, postcondiciones y resultados
esperados, que determinan si una unidad,
componente funcionan correctamente
• Suite de Prueba
– Es una colección de casos de pruebas
relacionados y asociados a un elemento de
prueba
16
Suite de Prueba
Caso de prueba
1
Caso de prueba
2
…
Caso de prueba
n

Niveles de prueba
• Los niveles de pruebas definen los tipos de pruebas que se deben realizar
y el orden en que se deben ejecutar
Nivel de
Aceptación
Nivel del
Sistema
Nivel de
Integración
Nivel de
Unidad
Pruebas de
Unidad
•Prueban el
código de cada
componente
Pruebas de
Integración
•Prueban las
conexiones entre
los componentes
arquitectónicos
Pruebas
del
Sistema
•Prueban los
requisitos
funcionales y no
funcionales
Pruebas de
Aceptación
•Prueban las
necesidades
reales de los
usuarios

Los procesos fundamentales de las pruebas
• Las pruebas van más allá de la simple ejecución de programas para
localizar defectos
– Las pruebas incluyen un conjunto de procesos y actividades previas y
posteriores a su ejecución
• Los procesos fundamentales de las pruebas de software según el ISTQB*
* International Software Testing Qualifications Board
Planificación y control de las pruebas
Análisis y diseño de las pruebas
Implementación y ejecución de las pruebas
Evaluación de los criterios de éxitos y elaboración de reportes
Cierre de las actividades de pruebas

Técnicas de prueba caja negra
• Las pruebas caja negra ignoran la estructura interna del componente o
unidad de prueba
• Se centran en los requisitos funcionales del sistema
• Evalúan que tan bien el componente satisface sus requisitos funcionales
– Para lo cual se requiere conocer los datos de entrada necesarios para
ejecutar la función
• Técnicas caja negra más conocidas:
– Particiones equivalentes
– Análisis de los valores límites
– Conjetura de errores
– Pruebas aleatorias
Función del
componente
datos de entrada resultados

Técnicas de prueba caja negra
• Particiones equivalentes
– Esta técnica divide los datos de entrada del componente en un número finito
de clases de equivalencia
– Una clase de equivalencia representa un conjunto de estados válidos y no
válidos para una condición de entrada dada
– Una condición de entrada es una restricción de un parámetro o variable de
entrada establecida como un requisito o regla de negocio
– Ejemplo de una condición (regla de negocio):
• El costo de un producto está en el rango [0, 9999999]
– Clases Válidas: conjuntos de valores de entrada válidas
– Ej. 0 ≤ costo ≤ 9999999
• Clases Inválidas: conjuntos de valores de entrada inválidos
– Ej. costo < 0 y costo > 9999999
0 9999999
clase inválida clase válida clase inválida

Técnicas de pruebas caja blanca
• Las pruebas caja blanca toman en consideración la estructura interna
(código fuente) del programa
– Recorre cada uno de los posibles caminos lógicos (flujos de control)
– Es necesario determinar los datos de entrada que permitan recorrer cada
flujo de control

Pruebas del camino básico
• Definen un conjunto básico de caminos de ejecución del componente que
garantizan que cada instrucción es ejecutada por lo menos una vez
• Emplean grafos de flujo para modelar el flujo de control de un programa
y determinar su conjunto de caminos básicos
• Diagramas de grafo de flujo
– Constructos básicos para modelar instrucciones:
Secuencias If-then-else Do-while Repeat-until
Selección múltiple
(Case)

• Grafos de flujo
– Se elaboran analizando el flujo de control del programa, el cual se representa
normalmente mediante diagramas de flujo
– Ejemplo:
1,2,3
5 4,9
76
10
8
1
3
4
2
6 7
5
8
10
9
Nodos asociados
a decisiones

• Grafos de flujo
– En las instrucciones IF-THEN-ELSE, las condiciones compuestas se modelan
usando un subgrafo de flujo
• Una condición compuesta está formada por uno o más operadores
lógicos AND, OR, NAND, NOR
• Los nodos que contienen condiciones se denominan NODOS PREDICADO
– Ejemplo: subgrafo de la instrucción IF A OR B THEN I1 ELSE I2
• Cada condición simple forma un nodo predicado
: nodo predicado
A
I1I2
B

• A partir del grafo de flujo, se determina el número de CAMINOS
INDEPENDIENTES
– Un camino independiente, en un grafo de flujo, es un camino que contiene al
menos un arco que no está incluido en ningún otro camino
– El número de caminos independientes se determina mediante la complejidad
ciclomática del Grafo de Flujo
• La COMPLEJIDAD CICLOMATICA es una métrica de software que
determina la complejidad de la lógica de un programa
– Para un grafo de flujo G, la complejidad ciclomática se define como:
• CC(G) = Número de Arcos - Número de Nodos + 2
• ó
• CC(G) = Número de Nodos Predicado + 1

• Pruebas del camino básico:
• ¿Cuál es la complejidad ciclomática
(CC) del grafo G?
– CC = NP + 1 = 2 + 1 = 3
• ¿Cuántos caminos independientes (CI)
tiene el grafo?
– CI = CC = 3
• ¿Cuántos casos de prueba deben
diseñarse para asegurar que cada
instrucción del programa representado
por G se ejecuta al menos una vez?
– Igual a CC = 3
1,2,3
5 4,9
76
10
8
Nodos predicado (NP) :
Grafo de flujo G

• Procedimiento para el diseño de casos de prueba
del camino básico
– A partir del código fuente del componente, elabore
el grafo de flujo
– Determinar la complejidad ciclomática del grafo
• CC(G) = Número de Nodos Predicado + 1 = 3 +
1 = 4
– Enumerar cada uno de los caminos independientes
• 1,11
• 1,2,,3,4,5,10,1,11
• 1,2,3,6,7,9,10,1,11
• 1,2,3,6,8,9,10,1,11
– Preparar un caso de prueba para cada camino
independiente
• Usar las condiciones de los nodos predicados
para determinar los datos de prueba de cada
camino
1
2,3
4, 5
8
6
9
7
10
11

Desarrollo de Software Guiado por Pruebas
Sesión 2:
Caso de Estudio: Diseño de la Aplicación

Caso de Estudio
• Desarrollar una aplicación web para la gestión de eventos tales como
seminarios, talleres, conferencias, congresos. La aplicación debe contar con
los siguientes servicios:
– Creación, edición y eliminación de contactos. Incluye los datos personales de cada
contacto y el país y estado de residencia
– Creación, edición y eliminación de eventos
– Configuración de mensajes para la comunicación con los participantes
– Envío masivo de correos, con la finalidad de:
• Realizar las invitaciones al evento
• Informar a los inscritos sobre el estado de su aprobación
• Recordarles a los participantes la fecha del evento
• Promocionar productos y material del evento
• Enviar carta de agradecimiento por su participación
• Entre otros..
– Inscripción de participantes al evento
– Aprobación de participantes al evento
– Checkin de participantes el día de inicio del evento
– Estadísticas de invitados, inscritos, aprobados, rechazados, por aprobar, asistentes,
ausentes, correos enviados por tipo de remitentes, etc.
29

Diseño – Modelo Funcional – Usuarios
uc Actores
Usuario
Registrado
Usuario no
registrado
Gerente de
eventos
Participante Gestor checkin Gerente de
mercadeo
Gestor de aprobación

Diseño – Modelo Funcional - Casos de
uso
uc Casos de Uso
Gestión de eventos
Gestión de
inscripciones
Gerente de eventos
EventoTDD
Estadísticas de
eventos
Participante
Gerente de mercadeo

uc Gestión de eventos
Gerente de
eventos
CRUD de eventos
CRUD de mensajes
de correo
CRUD de contactos
Gerente de mercadeo
CRUD de paises
CRUD de estados
Crear nuevo país
Editar país
Eliminar país
Listar países
«invokes»
«extend»
«extend»
«extend»
uso

uc Gestión de inscripciones
Gestor checkin
Aprobar participantes al
evento
Preinscribirse al evento
Realizar checkin del
participante
Participante
Envío de correos masivos
Gerente de
mercadeo
Gerente de
eventos
Gestor de
aprobación
uso

uc Estadísticas de eventos
Mostrar estadísticas de
invitaciones
Mostrar estadisticas de
participantes
correos
inscripciones
Gerente de mercadeo
Gerente de
eventos
Gestor de aprobación
uso

Diseño – Modelo Funcional (Flujo de Eventos)
Caso de Uso: Crear nuevo país

Diseño – Modelo Estructural
(diagrama de clases)
class Contactos
Contacto
^ id :int
# nombres :string
# apellidos :string
# doc_identidad :string
^ email :string
# telefono :string
# estado_id :int
# sexo_id :int
Pais
^ nombre :string
Estado
^ nombre :string
# pais_id :int
«enumeration»
Sexo
Masculino
Femenino
Evento
^ id :int
^ nombre :string
# descripcion :text
# fecha_inicio :date
# fecha_fin :date
# num_invitados :int
# lugar :string
InscripcionEvento
^ id :int
# fecha :date
- fecha_tipo_aceptacion :datetime
- check_in :bool = false
- fecha_check_in :datetime
# evento_id :int
# contacto_id :int
# tipo_aceptacion_id :int
Mensaje
^ id :int
# asunto :string
# remitente :bool = true
# descripcion :string
- enlace :string
# evento_id :int
EnvioMail
^ id :int
# fecha :datetime
# mensaje_id :int
# evento_id :int
# tipo_remitente_id :int
«enumeration»
TipoRemitente
Todos los contactos
Preinscritos
Aprobados
Rechazados
Por aprobar
Asistentes
No asistentes
«enumeration»
TipoAceptacion
Por aprobar
Aprobado
Rechazado
*
** *
*
*
**
**

Diseño – Interfaz Gráfica: CRUD País

Diseño – Modelo Dinámico (diagrama de
estado)
stm InscripcionEvento
Invitacion
Preinscripcion
Aprobada
Por AprobarRechazada
Checkin
Initial
Final

Diseño – Modelo Dinámico (diagrama de
secuencia)
sd CRUD Contactos
Gerente de eventos
(from Actores)
GUI-Contactos ContactoController
Contacto
opt Operaciones CRUD
[accion='nuevo']
[accion='editar']
[accion='eliminar']
[accion='mostrar']
index()
all() :@contactos
index.haml(@contactos)
contactos.js()
seleccionar accion()
new()
new() :@contacto
new.haml()
_form.haml(@contacto)
ingresar datos de contacto()
create(contacto_params)
new(contacto_params) :@contacto
save()
index()
edit(contacto.id)
find(contacto.id) :@contacto
edit.haml()
_form.haml(@contacto)
editar los datos del contacto()
update(contacto_params)
find(params_id) :@contacto
update(contacto_params)
index()
destroy(contacto.id)
destroy()
index()
show(contacto.id)
show()
_form(@contacto)

Conclusión
• Las BBDD NoSQL son una clara alternativa a los RDBMS
– Sobre todo para algunas aplicaciones sociales y web que requieren
elevada escalabilidad
• No son idóneas para todo, de hecho en la mayoría de los
casos las RDBMS deberían seguir siendo la primera opción:
– La capacidad de hacer JOIN y las garantías ACID son muy importantes
para muchas aplicaciones
• Es muy posible que los RDBMS actuales evolucionen
para incorporar capacidades de NoSQL

BIBLIOGRAFIA
Referencias
•David Loshin, “Business Intelligence: The Savvy Manager's Guide”, The Morgan
Kaufmann Series on Business Intelligence, 2010
•Stephan Kudyba , Richard Hoptroff , “Data Mining and Business Intelligence: A Guide to
Productivity”, IGI Publishing, 2011
•José Hernández, José Ramírez Quintana, César Ferri Ramírez, "Introducción a la Minería
de Datos" Editorial Pearson, 2004
•Peter F. Drucker, “Gestión del Conocimiento”, Deusto S.A. ediciones, 2009
•Ralph Kimball, Margy Ross “The Data Warehouse Toolkit: The Complete Guide to
Dimensional Modeling”, Wiley; 2 edition, 2009.
•Judith Hurwitz, Alan Nugent, Fern Halper, Marcia Kaufman, “Big Data For Dummies,”,
Wiley, 2013
•I. H. Witten, E. Frank & M. A. Hall "Data Mining. Practical Machine Learning Tools and
Techniques with Java Implementations. Third Edition". Morgan Kaufmann Publishers. San
Francisco, California, 2011.
•Michael Milton, “Head First Data Analysis”, O'Reilly Media, 2009

Referencias
• Fuente: Watts, D.J., Strogatz, S.H.(1998) Collective dynamics of 'small-world' networks. Nature
393:440-442
• Networks, Crowds, and Markets Reasoning About a Highly Connected World
pagina descargar libro: http://www.cs.cornell.edu/home/kleinber/networks-book/networks-book.pdf
• The structure and function of complex networks
M. E. J. Newman
pagina descargar libro:http://www-personal.umich.edu/~mejn/courses/2004/cscs535/review.pdf
• Introductory social network analysis with Pajek
Lada Adamic -Copyright 2008, Lada Adamic
pagina descargar libro: http://ocw.mit.edu/courses/economics/14-15j-networks-fall-
2009/assignments/MIT14_15JF09_pajek.pdf
• LIBRO: Exploratory social network analysis with Pajek
pagina descargar libro: http://courses.arch.ntua.gr/fsr%2F144992/Pajek-Manual.pdf

Referencias
• Albert, R. and Barab¶asi, A.-L., Statistical mechanics of complex networks, Rev. Mod. Phys. 74, 47{97
(2002).
En español:Albert, R. y Barab'asi, A.-L., mecánica estadística de redes complejas, Rev. Mod. Phys.
74, 47-97 (2002).
• Wasserman and Faust, Social Network Analysis, Cambridge
University Press, 1994
• Martínez, A., Y. Dimitriadis, B. Rubia, E. Gómez and P. de la
Fuente. Combining qualitative evaluation and social network analysis for the study of classroom social
interactions. Computers and Education 41(4): 355-368, 2003.

Referencias
• Data Mining. Practical Machine Learning Tools and Techniques with Java Implementations.
• http://177.101.20.73/docs/wittenfrank.pdf
• Data Mining (Minería de datos: )
Practical Machine Learning Tools and Techniques(Prácticos Herramientas de Aprendizaje Automático y
Técnicas)
PAGINA DE DECARGA:
https://www.google.com.co/url?sa=t&rct=j&q=&esrc=s&source=web&cd=5&cad=rja&uact=8&ved=0CD8QFjAE
&url=http%3A%2F%2Fcs.famaf.unc.edu.ar%2F~laura%2Fllibres%2Fdm.pdf.gz&ei=WfnDVOiWGcmHsQTbu4
HAAw&usg=AFQjCNEGHvTbn3cFVlvK3m3aCgWEsgZHNA&bvm=bv.84349003,d.eXY
• LIBRO: MongoDB: The Definitive Guide
AUTOR: Kristina Chodorow and Michael Dirolf
Publicado por la editorial: O’Reilly Media, Inc.,
• Cassandra
– “NoSQL – Not only SQL (Introduction to Apache Cassandra)”
• http://www.scriptandscroll.com/3508/technology/nosql-not-only-sql-introduction-to-apache-
cassandra/#.TtonPmMk6nA
– DataSax company:
• http://www.datastax.com/about-us/about-datastax
– Getting started with CQL:
• http://www.datastax.com/docs/0.8/dml/using_cql
– http://cassandra.apache.org/

• CouchDB
– Exploring CouchDB, Joe Lennon,
• http://www.ibm.com/developerworks/opensource/library/os-CouchDB/index.html
– CouchDB tutorial
• http://net.tutsplus.com/tutorials/getting-started-with-couchdb/
– CouchDB for geeks:
• http://www.slideshare.net/svdgraaf/CouchDB-for-geeks?from=share_email
– CouchDB site:
• http://CouchDB.apache.org/
– CouchApp.org: The ‘Do It Yourself’ Evently Tutorial
• http://couchapp.org/page/evently-do-it-yourself
– CouchApp.org: What the HTTP is CouchApp?
• http://wiki.couchapp.org/page/what-is-couchapp
– Tutorial: Using JQuery and CouchDB to build a simple AJAX web application
• http://blog.edparcell.com/using-jquery-and-CouchDB-to-build-a-simple-we
– CouchApp site:
• http://couchapp.org/page/getting-started
Referencias

• NoSQL vs. RDBMS
– Riyaz -- Thanks for the question regarding "NOSQL vs. RDBMS databases",
version 10r2
• http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:2664632
900346253817
– NoSQL or not NoSQL?
• http://www.slideshare.net/ruflin/nosql-or-not-nosql/download
– Comparativa de diferentes soluciones NoSQL:
• http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis
– SQL vs. NoSQL
• http://www.linuxjournal.com/article/10770
Referencias

Bibliografía
Fuentes bibliográficas
[1] Social Network Analysis, A Brief Introduction.http://www.orgnet.com/sna.html
Social network analysis (SNA): http://en.wikipedia.org/wiki/Social_network_analysis
Red social
https://es.wikipedia.org/wiki/Red_social
Big-Data-for-Dummies
• http://files.glou.org/it-ebooks/big_data_for_dummies.pdf
• http://www.re-store.net/dnn/Portals/0/Images/dummies/HadoopForDummies.pdf
• http://www.mosaic.geo-strategies.com/wp-content/uploads/2013/10/Big-Data-for-
Dummies.pdf
Data Mining. Practical Machine Learning Tools and Techniques with Java Implementations.
• http://177.101.20.73/docs/wittenfrank.pdf
• Wasserman and Faust, Social Network Analysis, Cambridge University Press, 1994
• Martínez, A., Y. Dimitriadis, B. Rubia, E. Gómez and P. de la Fuente. Combining qualitative
evaluation and social network analysis for the study of classroom social interactions.
Computers and Education 41(4): 355-368, 2003.

Bibliografía
Fuentes bibliográficas
Bases de Datos No Relacionales (NoSQL)
http://es.slideshare.net/dipina/nosql-cassandra-couchdb-mongodb-y-neo4j
NoSQL: Introducción a las Bases de Datos no estructuradas
http://es.slideshare.net/dipina/nosql-introduccin-a-las-bases-de-datos-no-estructuradas
MongoDB: la BBDD NoSQL más popular del mercado
http://es.slideshare.net/dipina/mongodb-la-bbdd-nosql-ms-popular-del-mercado
NoSQL: la siguiente generación de Base de Datos
http://es.slideshare.net/dipina/nosql-la-siguiente-generacin-de-base-de-datos

Fin de la presentación.
MUCHAS GRACIAS
Copyright 2015, Todos los Derechos
Reservados.
Sabiduría ante todo; adquiere sabiduría;
Y sobre todas tus posesiones adquiere inteligencia.
Engrandécela, y ella te engrandecerá.
Proverbios 4:7-9

Desarrollo de Software Guiado por Pruebas

Más contenido relacionado

La actualidad más candente

Destacado

Similar a Desarrollo de Software Guiado por Pruebas

Más de .. ..

Último

Desarrollo de Software Guiado por Pruebas