Publicidad

Desarrollo de Software Guiado por Pruebas

.. ..
26 de May de 2016
Publicidad

Más contenido relacionado

Publicidad
Publicidad

Desarrollo de Software Guiado por Pruebas

  1. UNIVERSIDAD DE PAMPLONA Ruby on Rails. Ing. Diego Hernando Torres Valencia Desarrollo de software guiado por pruebas: Ruby on Rails.
  2. 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 Ing. Diego Hernando Torres Valencia 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
  3. 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
  4. DesarrollodeSoftwareguiadoporPruebasenRoR 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
  5. DesarrollodeSoftwareguiadoporPruebasenRoR 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
  6. Desarrollo de Software Guiado por Pruebas Sesión 1: Fundamentos Conceptuales de Pruebas Ing. Diego Hernando Torres Valencia
  7. 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
  8. 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 (Test-Driven Development =Guiado Por Pruebas de Software) ?
  9. PruebasdeSoftware:TécnicasyGestiónDesarrollodeSoftwareguiadoporPruebasenRoR • 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 (Test-Driven Development =Guiado Por Pruebas de Software) ?
  10. PruebasdeSoftware:TécnicasyGestiónDesarrollodeSoftwareguiadoporPruebasenRoR 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
  11. DesarrollodeSoftwareguiadoporPruebasenRoR 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
  12. DesarrollodeSoftwareguiadoporPruebasenRoR Pruebas de Software: Conceptos Fundamentales 12 Los conceptos fundamentales de las Pruebas
  13. DesarrollodeSoftwareguiadoporPruebasenRoR 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
  14. DesarrollodeSoftwareguiadoporPruebasenRoR 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
  15. DesarrollodeSoftwareguiadoporPruebasenRoR 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)
  16. PruebasdeSoftware:TécnicasyGestiónDesarrollodeSoftwareguiadoporPruebasenRoR 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
  17. DesarrollodeSoftwareguiadoporPruebasenRoR 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
  18. DesarrollodeSoftwareguiadoporPruebasenRoR 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
  19. DesarrollodeSoftwareguiadoporPruebasenRoR 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
  20. DesarrollodeSoftwareguiadoporPruebasenRoR 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
  21. DesarrollodeSoftwareguiadoporPruebasenRoR 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
  22. DesarrollodeSoftwareguiadoporPruebasenRoR 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)
  23. DesarrollodeSoftwareguiadoporPruebasenRoR Pruebas del camino básico • 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
  24. DesarrollodeSoftwareguiadoporPruebasenRoR Pruebas del camino básico • 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
  25. DesarrollodeSoftwareguiadoporPruebasenRoR Pruebas del camino básico • 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
  26. DesarrollodeSoftwareguiadoporPruebasenRoR Pruebas del camino básico • 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
  27. DesarrollodeSoftwareguiadoporPruebasenRoR Pruebas del camino básico • 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
  28. Desarrollo de Software Guiado por Pruebas Sesión 2: Caso de Estudio: Diseño de la Aplicación Ing. Diego Hernando Torres Valencia
  29. PruebasdeSoftware:TécnicasyGestiónDesarrollodeSoftwareguiadoporPruebasenRoR 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
  30. 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
  31. 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
  32. 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» Diseño – Modelo Funcional - Casos de uso
  33. 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 Diseño – Modelo Funcional - Casos de uso
  34. uc Estadísticas de eventos Mostrar estadísticas de invitaciones Mostrar estadisticas de participantes Mostrar estadísticas de correos Mostrar estadísticas de inscripciones Gerente de mercadeo Gerente de eventos Gestor de aprobación Diseño – Modelo Funcional - Casos de uso
  35. Diseño – Modelo Funcional (Flujo de Eventos) Caso de Uso: Crear nuevo país
  36. Diseño – Modelo Funcional (Flujo de Eventos) Caso de Uso: Crear nuevo país
  37. 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 * ** * * * ** **
  38. Diseño – Interfaz Gráfica: CRUD País
  39. Diseño – Interfaz Gráfica: CRUD País
  40. Diseño de Pruebas de Unidad
  41. Diseño – Modelo Dinámico (diagrama de estado) stm InscripcionEvento Invitacion Preinscripcion Aprobada Por AprobarRechazada Checkin Initial Final
  42. 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) find(contacto.id) :@contacto destroy() index() show(contacto.id) find(contacto.id) :@contacto show() _form(@contacto)
  43. 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
  44. 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
  45. Referencias
  46. 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
  47. 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.
  48. 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/
  49. • 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
  50. • 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
  51. 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.
  52. 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
  53. 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
Publicidad