¿Quién soy yo?

00

Iwan van der Kleijn

I’ve an enduring interest in the integration of heterogeneous information systems, especially in the cross-cut between system and human interfaces. This is currently being rejuvenated by the possibilities offered and challenges posed by the integration of new client and server technologies: mobile applications, RIA, SOA & Cloud Computing.

I work and live in Valencia, Spain and have been here with my family since 2005. Now working for more than twenty-five years in the industry, I’ve kept myself busy as developer, analyst, IT architect, manager and Technical Director for companies like Capgemini, Sogeti, KPMG, Creyfs, Valoris and Exentric Thinking in the Benelux, United Kingdom and Spain. I am currently working as CTO at Encamina.

Academia vs Business

¿Quiénes somos?

01

Nuestra forma de pensar

Somos una consultora especializada en tecnología y productos Microsoft, que ofrece mejoras de competitividad a organizaciones medianas y grandes, mediante soluciones BI, ECM, CRM y BPM, a través del canal web, la nube y la movilidad empresarial. Nos apasiona trabajar desde el optimismo, con creatividad, en equipo, cuidando la experiencia de usuario y sintiendo que todos ganamos.

Ser líderes en el ecosistema Microsoft para el ámbito nacional y algún día, un referente internacional en soluciones y servicios de nicho a través de la nube. Y queremos lograrlo con intensidad, desde el lugar donde más nos gusta vivir, con un equipo brillante, colaborando para clientes excelentes, y generando riqueza para nuestra sociedad, nuestros profesionales y nuestra empresa.

Nuestros valores

Es la responsabilidad profunda que nos vincula a nuestros clientes, a nuestros proyectos, a nuestros compañeros y a ENCAMINA

es la capacidad de adaptarse con facilidad a las nuevas circunstancias o necesidades, reconduciendo las acciones oportunamente para lograr una mejor relación y entendimiento.

es la cualidad personal de anticiparse a los demás en hacer, decir o proponer algo. Es ser pro-activos, prever el futuro, proponer mejoras y encontrar soluciones.

Realizar el trabajo con vitalidad, alegría y ánimo, de forma que además nos

satisfaga y nos divierta. Es enfocar los retos siempre desde el lado positivo.

Trabajamos coordinadamente por intereses comunes en un ambiente de

colaboración. Implica respeto mutuo, solidaridad, lealtad, amistad,

generosidad, compartiendo los frutos del trabajo colectivo.

es el sentimiento que, emanando de uno mismo, nos compromete con nuestros

actos y sus consecuencias. Es actuar de forma eficaz y eficiente, haciendo lo

necesario para lograr los objetivos perseguidos.

Es la actitud fresca, optimista y comprometida que utiliza el ingenio y la creatividad para encontrar soluciones de tecnología y talento que mejoren el presente de las personas, la empresa y nuestra sociedad.

Pensar en colores

¿Qué hacemos?

02

¿Qué hacemos?

Diseño web, Usabilidad / UX y AI Social Enterprise Soluciones CMS, WEB y e-commerce Arquitecturas SOA, Tecnología .Net framework

AZURE Ingeniería de Sistemas Microsoft y virtualización

Consultoría específica MS Dynamics CRM y CRM on-line Multidispositivo-Multiplataforma HTML5 – CSS3 - JS – Sencha SharePoint EVERYWARE

ECM , BPM y BI SharePoint 2013 y Office 365 PerfornacePoint, SQL Server NINTEX workflow y AvePoint

Soluciones CRM y enterprise Mobility

Soluciones de Colaboración, Conocimiento e inteligencia de negocio.

Marketing on-line y 2.0

Arquitectura software y tecnología

13 años construyendo soluciones brillantes

Microsoft Partner del año Pyme 2013

Tagcloud de nuestro mundo tecnológico

•  Estamos certificados en las competencias de Portals & Collaboration (Gold), Business Intelligence (Gold), Mobility, y Cloud. •  Desde el 2003, con la primera versión de Sharepoint, comenzamos a desarrollar soluciones de

intranet y portales del empleado, portales de colaboración, portales de proveedores, gestión de contenidos, extranets, gestión de la Calidad e ISO-9000, gestión del talento, etc.

•  Hemos utilizado MS Sharepoint 2003, los WSS3.0, MOSS2007, SP2010, SP2013 y SharePoint on-line/Office365 como framework de aplicaciones transaccionales e integrando otras aplicaciones en él. •  Hemos utilizado el SDK para pedirle más y lo hemos conectado a subsistemas externos como

scanners, LDAPs, XML Web Services, etc. , así como aplicaciones externas (como MS Dynamics CRM, Project Server, etc.)

•  Nuestras capacidades en arquitectura .Net, junto con el expertisse del producto, nos permiten proyectos de solución integral donde intervenga tanto la consultoría como la integración.

Porqué somos buenos en SharePoint

ü  Como intranet y gestión del conocimiento de la empresa. ü  Como sistema de colaboración de grupos de trabajo. ü  Como plataforma para aplicaciones transaccionales de proveedores de la cadena de

valor de la empresa. ü  Como sistema de gestión de proyectos con diversas organizaciones implicadas. ü  Como extranet de clientes donde gestionar los servicios con ellos. ü  Como sistema de gestión documental integrado con sistemas de scanner, distribución

de información, etc. ü  Como help-desk de gestión de incidencias ü  Como cuadro de mando – BI de la organización. ü  Como plataforma .TV (integrada con Youtube.com) y como gestión de revistas

integradas. ü  Como sistema de gestión de la Calidad (ISO) en la empresa. ü  Como portal web CMS y agenda de eventos con edición distribuida.

Cosas que hemos hecho con SharePoint

Logramos de SharePoint o cualquier otro sistema web un interfaz adaptativo o “responsive” mediante diseños específicos.

Pero Enterprise Mobility – SharePoint EVERYWARE significa hacer que las aplicaciones, no solo sean responsive o adaptativas, sino que aprovechen todas las capacidades del dispositivo y el propio contexto del usuario cuando está en campo o bien fuera de la empresa.

SharePoint Everyware mediante interfaces adaptativos / Responsive

•  Para ENCAMINA, extender SharePoint y otros aplicativos empresariales a la movilidad implica desarrollar aplicaciones multidispositivo basadas en HTML5, JS y CSS3 aprovechando todas las utilidades y APIs que facilitan su arquitectura y desarrollo (como Sencha o Apache Córdoba-PhoneGap) y conectarlas, mediante SOAP, XML sobre HTTP o JSON a través de HTTP, con el ESB empresarial, o con otros servicios de la nube o nuestro típico broker facilitador de los servicios que ofrece SharePoint (o con SharePoint directamente).

•  También la comunicación se da por la vía inversa mediante mensajes PUSH.

Tecnologías SharePoint Everyware

Android

Aplicación  de  servidor

Llamadas  servicio  web  JSON  (o  SOAP)

Mensajes  “Push”  

Servicios web ágiles y enfocados a las necesidades y aprovechando las capacidades de la información y servicios contenidas en SharePoint.

Descarga solo la información a actualizar.

Permite la interacción offline con el GPS del terminal

Introduce nuevas posibilidades y servicios interactivos con los usuarios visitantes.

Diferentes formatos y espacios de presentación de información en tablets y/o smartphones.

Arquitectura de la solución SharePoint Everyware

Capa  SOA  

HelpingHand es la aplicación multidispositivo que permite trabajar autónomamente y de forma

desconectada y ubicua al usuario, de cualquier role,

con las incidencias y peticiones de HelpShare.

HelpingHand está desarrollado en HTML5 pero el backend y master de todo el proceso y de la

información central es una plataforma SharePoint en

la nube pública o privada de la empresa.

HelpingHand consume los servicios de SharePoint (personalizados en HelpShare) a través de un broker que simplifica el trabajo con las listas de SharePoint

que se sincronizan e intercambian.

Ejemplo típico SharePoint Everyware: HelpingHand sobre HelpShare

ECM

Intranet

Portal del empleado

Comités y sitios de colaboración

Extranet clientes y proveedores

Gestión Documental

Hemeroteca y canal.tv

BPM

Gestión calidad ISO9000 y seguridad

Solicitudes/autoservicio del empleado

HelpDesk & Ticketing

Registro de Entrada

Ciclo de Compras

Integración BPM con SAP

CRM

Fuerza de Ventas y Gestión de Campañas

CRM para hoteles

CRM para FARMA

CRM para asociaciones

Encuestas on-line

E-mail Marketing (IMPACTO)

WEB

Portales web (CMS)

Aplicaciones web

Usabilidad , diseño web y UX

e-Commerce y TPV

Comunicación web 2.0

Sistemas guía para consultoría

BI

PerformancePoint & PowerPivot & SQL

CMI hospitalario

CMI de Operaciones

Plataformas de Reporting

Gestión de Proyectos con Project Server

Expedientes y proyectos con SharePoint

Algunas soluciones de empresa

Pensar en colores: Pensar en personas

Pensar en colores: Pensar en participación con el cliente

Pensar en colores: Pensar en UX & Business & Tecnología integrado

UX

Pensar en colores: Pensar en diseño integrado

Pensar en colores: Pensar en un equipo multidisciplinario

Lo que no hablamos (y tampoco vamos a hablar) en ICT

03

No hablamos de él

Aunque deberíamos hablar de ellos

Metáforas equivocadas: no trabajamos así

Y tampoco trabajamos así

Aunque es posible que trabajamos en el “Code mine”

Seguro que no somos

Aunque podríamos ser

Pero no es muy políticamente correcto

O, alternativamente

Lea acerca de esto en este libro

Como Brooks escribió en 1975

“...Computer programming, however, creates with an exceedingly tractable medium. The programmer builds from pure thought-stuff: concepts and very flexible representations thereof. Because the medium is tractable, we expect few difficulties in implementation; hence our pervasive optimism. Because our ideas are faulty, we have bugs; hence our optimism is unjustified…”

“tractable” => Managable

Hacer proyectos en ICT

04

“….In 1956, a group of computer scientists at IBM set out to build the world's fastest supercomputer. Five years later, they produced the IBM 7030 -- a.k.a. Stretch -- the company's first transistorized supercomputer, and delivered the first unit to the Los Alamos National Laboratory in 1961. Capable of handling a half-million instructions per second, Stretch was the fastest computer in the world and would remain so through 1964……

Nevertheless, the 7030 was considered a failure…..”

Proyectos fracasados & ICT: historia

“Fracaso" no sólo son "fallos catastróficos", sino también los retrasos, las grandes cantidades de errores, discrepancias con los requisitos de los clientes.

Es decir: problemas que ponen en peligro los márgenes de los proyectos, la continuación del proyecto o incluso la continuación de la relación con el cliente

¿Por qué fracasan los proyectos?

ü  Cualidad de equipo y forma de trabajar

ü  Cualidad de procesos

ü  "Forma de trabajar" y "procesos" NO son sinónimos

¿Por qué fracasan los proyectos? Debilidades:

“...Qué es una prueba unitaria / un "closure" / un interfaz ReST...”

“…¿Cómo hacer pruebas unitarias / implementar un "closure" / diseño de una interfaz REST…”

“…Yo no sabía que se suponía que debía hacer pruebas unitarias / utilizar un "closure" aquí / implementar un interfaz Resto…”

¿Por qué fracasan los proyectos? Algunas citas:

ü  Conocimiento es importante, pero también: ü  la actitud profesional, tal como

ü  el pensamiento "out of the box"

ü  En España el nivel no esta mal pero tampoco es extraordinario.

ü  Contamos con equipos de programadores mas que ingenieros de software, “freakies” mas que aficionadas de tecnología

Estado y calidad de los equipos

ü  Organización jerárquica

ü  No hay entorno estandarizado (hay procesos(!); bastante. Este no es problema)

ü  No hay mentalidad de minimizar esfuerzo por automatización

ü  No hay mentalidad de reutilizar trabajo

ü  No hay visión arquitectónico / ingeniera de software

ü  No hay visión "desde punta de visto de usuario"

ü  No hay cultura de hacer pruebas.

ü  NO solo los “managers” y “programadores”(!); es algo general y cultural

Debilidades en España

Al final del día los problemas críticos son genéricos y comunes en todo el mundo:

ü  Incompetencia organizativa

ü  Falta de comunicación, falta de saber "que hacer ahora"

Pero más importante

Los problemas que se enfrentan al hacer proyectos

ü  La falta de un modelo, un ejemplo, "saber qué hacer"

ü  La falta de un léxico estándar, un vocabulario común sobre "qué hacer"

ü  La falta de una manera común de entender "qué hacer”

Como un aparte

ü  No hay soluciones mágicas.

ü  Cualquier solución a los problemas antes mencionados es dependiente de la calidad de personas

Scrum como metodología de proyectos

•  Scrum como posible solución •  Muchas alternativas: Kanban, DSDM, Lean, Extreme Programming,

RUP (todavía)

•  Pero Scrum es bien conocido, probada y adaptable

•  Scrum no debería ser una ortodoxia, y muchas veces se convierte en uno(!)

Gestión de proyectos: SCRUM

05

Scrum en 100 palabras

•  Scrum es un proceso ágil que nos permite centrarnos en ofrecer el más alto valor de negocio en el menor tiempo.

•  Nos permite rápidamente y en repetidas ocasiones inspeccionar software real de trabajo (cada dos semanas o un mes).

•  El negocio fija las prioridades. Los equipos se auto-organizan a fin de determinar la mejor manera de entregar las funcionalidades de más alta prioridad.

•  Cada dos semanas o un mes, cualquiera puede ver el software real funcionando y decidir si liberarlo o seguir mejorándolo en otro sprint.

•  Software comercial

•  Desarrollos internos

•  Desarrollos bajo Contrato

•  Proyectos Fixed-price

•  Aplicaciones Financieras

•  Aplicaciones certificadas ISO 9001

•  Sistemas Embebidos

•  Sistemas con requisitos 7x24 y 99.999% de disponibilidad

•  Joint Strike Fighter

• Desarrollo de video juegos

• Sistemas críticos de soporte vital, aprobados por laFDA

• Software de control satelital

• Sitios Web

• Software para Handheld

• Teléfonos portátiles

• Aplicaciones de Network switching

• Aplicaciones de ISV

• Algunas de las más grandes aplicaciones en uso

Scrum ha sido utilizado para:

•  Equipos auto-organizados

•  El producto avanza en una serie de “Sprints" de dos semanas a un mes de duración

•  Los requisitos son capturados como elementos de una lista de “Product Backlog"

•  No hay prácticas de ingeniería prescritas

•  Utiliza normas generativas para crear un entorno ágil para la entrega de proyectos

•  Uno de los “procesos ágiles”

Características

El Manifesto Ágil – una declaración de valores

Procesos  y  herramientas  

Individuos  e  interacciones  

sobre  

Seguimiento    de  un  plan  

Responder    ante  el  cambio  

sobre  

Fuente: www.agilemanifesto.org

Documentación  exhaus?va  So@ware  que  funciona   sobre  

Negociación  de  contratos    

Colaboración    con  el  cliente  

sobre  

Simple  

Complejo  Anarquía  

Tecnología  

Requ

isitos  

Lejos  de    Acuerdo  

Cerca  de  Acuerdo  

Cerca  de

 Ce

rteza  

Lejos  d

e  Ce

rteza  

Fuente:  Strategic  Management  and  Organiza0onal  Dynamics  by  Ralph  Stacey  in  Agile  So7ware  Development  with  Scrum  by  Ken  Schwaber  and  Mike  Beedle.  

Nivel de ruido de un proyecto

Scrum

Cancel  Gi@  wrap  Return  

Sprint 2-4 semanas

Objetivo del Sprint

Sprint Backlog

Incremento del producto potencialmente entregable

Product Backlog

24 horas

Poniendo todo junto

Enfoque: Sprint

•  En Scrum los proyectos avanzan en una serie de “Sprints” –  Análogo a las iteraciones en XP

•  La duración típica es 2–4 semanas o a lo sumo un mes calendario

•  La duración constante conduce a un mejor ritmo

•  El product es diseñado, codificado y testeado durante el Sprint

Sprints

Desarrollo secuencial vs. superpuesto

Source:  “The  New  New  Product  Development  Game”  by  Takeuchi  and  Nonaka.  Harvard  Business  Review,  January  1986.  

En  lugar  de  hacer  todo  de  una  cosa  a  la  vez  ...    

...los  equipos  Scrum  hacen  un  poco  de  todo  todo  el  ?empo  

Requisitos   Diseño   Código   Test  

•  Planee la duración del sprint en torno a cuánto tiempo usted puede comprometerse a mantener los cambios fuera del sprint

No hay cambios en un sprint

Cambios

Scrum Framework

• Product  owner  • ScrumMaster  • Team  

Roles  

• Sprint  planning  • Sprint  review  • Sprint  retrospec?ve  • Daily  scrum  mee?ng  

Reuniones  

• Product  backlog  • Sprint  backlog  • Burndown  charts  

Artefactos  

Scrum framework

• Sprint  planning  • Sprint  review  • Sprint  retrospec?ve  • Daily  scrum  mee?ng  

Reuniones  

• Product  backlog  • Sprint  backlog  • Burndown  charts  

Artefactos  

• Product  owner  • ScrumMaster  • Team  

Roles  

•  Define las funcionalidades del producto •  Decide sobre las fechas y contenidos de los releases

•  Es responsable por la rentabilidad del producto (ROI) •  Prioriza funcionalidades de acuerdo al valor del

mercado/negocio

•  Ajusta funcionalidades y prioridades en cada iteración si es necesario

•  Acepta o rechaza los resultados del trabajo del equipo

Product Owner

•  Representa a la gestión del proyecto •  Responsable de promover los valores y prácticas de

Scrum •  Remueve impedimentos •  Se asegura de que el equipo es completamente

funcional y productivo •  Permite la estrecha cooperación en todos los roles y

funciones •  Escudo del equipo de interferencias externas

El ScrumMaster

El Team

•  Típicamente de 5 a 9 personas •  Multi-funcional:

–  Programadores, testers, analistas, diseñadores, etc.

•  Los miembros deben ser full-time –  Puede haber excepciones (Ej.: Infraestructura, SCM, etc.)

•  Los equipos son auto-organizativos –  Idealmente, no existen títulos pero a veces se utilizan de acuerdo

a la organización •  Solo puede haber cambio de miembros entre los sprints

• Product  owner  • ScrumMaster  • Team  

Roles  

Scrum Framework

• Product  backlog  • Sprint  backlog  • Burndown  charts  

Artefactos  

• Sprint  planning  • Sprint  review  • Sprint  retrospec?ve  • Daily  scrum  mee?ng  

Reuniones  

Sprint  Planning  mee?ng  

Priorización  

•  Analizar  y  evaluar  el  Product  Backlog  •  Seleccionar  el  obje?vo  del  Sprint  

Planificación  

•  Decidir  como  alcanzar  el  obje?vo  del  Sprint  (diseño)  •  Crear  el  Sprint  Backlog  (tareas)  en  

base  a  los  temas  del  Product  Backlog  (user  stories  /  features)  •  Es?mar  Sprint  Backlog  en  horas  

Obje?vo  del  Sprint  

Sprint  Backlog  

Condiciones  del    Negocio  

Capacidad  del  Equipo  

Product  Backlog  

Tecnología  

Producto  Actual  

•  El equipo selecciona los temas a partir del Product Backlog que pueden comprometerse a completar

•  Se crea el Sprint Backlog –  Se identifican tareas y cada una es estimada (1-16 horas) –  Realizado colaborativamente, no solo por el ScrumMaster

•  El diseño de Alto Nivel es considerado

Planificación del Sprint

COMO planificador de vacaciones, YO QUIERO ver fotos de los hoteles.

Codificar  la  capa  intermedia  (8  hs)  Codificar  la  interfaz  de  usuario  (4)  Escribir  los  test  fixtures  (4)  Codificar  la  clase  foo  (6)  Actualizar  test  de  performance  (4)  

Daily Scrum

•  Parámetros

–  Diaria

–  Dura 15 minutos

–  Parados

•  No para la solución de problemas

–  Todo el mundo está invitado

–  Sólo los miembros del equipo, ScrumMaster y Product Owner, pueden hablar

–  Ayuda a evitar otras reuniones innecesarias

•  No es dar un status report al Scrum Master •  Se trata de compromisos delante de pares

Todos responden 3 preguntas

¿Qué hiciste ayer? 1

¿Qué vas a hacer hoy? 2

¿Hay obstáculos en tu camino?

3

•  El equipo presenta lo realizado durante el sprint

•  Normalmente adopta la forma de una demo de las nuevas características o la arquitectura subyacente

•  Informal –  Regla de 2 hs preparación

–  No usar diapositivas

•  Todo el equipo participa

•  Se invita a todo el mundo

Sprint review

Sprint retrospective

•  Periódicamente, se echa un vistazo a lo que funciona y lo que no •  Normalmente 15 a 30 minutos •  Se realiza luego de cada sprint •  Todo el equipo participa

–  ScrumMaster

–  Product owner

–  Equipo

–  Posiblemente clientes y otros

Start / Stop / Continue Todo el equipo se reúne y discute lo que les gustaría:

Comenzar  a  hacer  

Dejar  de  hacer  

Con?nuar  haciendo  Esto es sólo una de las muchas maneras de hacer una retrospectiva.

• Product  owner  • ScrumMaster  • Team  

Roles  

Scrum framework

• Sprint  planning  • Sprint  review  • Sprint  retrospec?ve  • Daily  scrum  mee?ng  

Reuniones  

• Product  backlog  • Sprint  backlog  • Burndown  charts  

Artefactos  

Product Backlog

•  Los requisitos •  Una lista de todos los trabajos

deseados en el proyecto •  Idealmente cada tema tiene valor

para el usuarios o el cliente •  Priorizada por el Product Owner •  Repriorizada al comienzo de cada

Sprint

Este  es  el  product  backlog  

Ejemplo de Product Backlog

Backlog item Estimación Permitir que un invitado a hacer una reserva. 3 Como invitado, quiero cancelar una reserva. 5 Como invitado, quiero cambiar las fechas de una reserva. 3

Como un empleado de hotel, puedo ejecutar informes de los ingresos por habitación disponible

8

Mejorar el manejo de excepciones 8 ... 30 ... 50

El objetivo del Sprint Una breve declaración de cuál será el foco del trabajo durante el sprint

Aplicación  con  B.Datos  

Servicios  Financieros  

Ciencias  Biológicas  Funciones  de  apoyo  técnico  necesarios  para  estudios  de  gené?ca  de  poblaciones.  

Soportar  más  indicadores  técnicos  que  la  empresa  ABC  en  ?empo  real  y  streaming  de  datos.  

Hacer  que  la  aplicación  se  ejecute  en  SQL  Server,  además  de  Oracle.  

•  Los individuos eligen las tareas •  El trabajo nunca es asignado

•  La estimación del trabajo restante es actualizada diariamente

•  Cualquier miembro del equipo puede añadir, borrar o cambiar el Sprint Backlog

•  El trabajo para el Sprint emerge

•  Si el trabajo no está claro, definir un tema del Sprint Backlog con una mayor cantidad de tiempo y subdividirla luego.

•  Actualizar el trabajo restante a medida de que más se conoce

Gestión del Sprint Backlog

Ejemplo de Sprint Backlog

Tareas  Codificar  UI  

Codificar  negocio  

Testear  negocio  

Escribir  ayuda  online  

Escribir  la  clase  foo  

L  8  

16  

8  

12  

8  

M  4  

12  

16  

8  

M   J  

4  

11  

8  

4  

V  

8  

8  Agregar  error  logging  

8  

10  

16  

8  

8  

Un Sprint Burndown Chart Ho

urs  

Hours  

40  

30  

20  

10  

0   Mon   Tue   Wed   Thu   Fri  

Tareas  Codificar  UI  Codificar  Negocio  Testear  Negocio  Escribir  ayuda  online  

L  8  16  8  12  

M   M   J   V  4  12  16  

7  11  

8  10  16   8  

50  

Escalabilidad

•  Normalmente los equipos son de 7 ± 2 personas –  La escalabilidad proviene de equipos de equipos

•  Factores a tener cuenta –  Tipo de aplicación

–  Tamaño del equipo

–  Dispersión del equipo

–  Duración del proyecto

•  Scrum se ha utilizado en múltiples proyectos de más de 500 personas

Reflexión

06

No son los procesos; son las personas

Para localizar o contactar con ENCAMINA puedes:

Contacto

Enviar un mail a:

encamina@encamina.com info@encamina.com

Llamar al 902 196 893 962 698 064 o 917 90 67 72

Enviar un fax al 962 698 063

O hablar personalmente con: •  Hugo de Juan, CEO •  Jaime Camarasa, Técnico Desarrollo

de Negocio

Visitarnos en: Jerónimo Roure 49 46520 Puerto de Sagunto, Valencia. Paseo Castellana, 135 - 7º 28046 , Madrid, Madrid

Partes de presentación basado en “Una Introducción a Scrum” de Ernesto Grafeuille (2008) Estas partes vienen con este aviso de Copyright:

•  Usted es libre de: –  Compartir- copiar, distribuir y trasmitir el trabajo

–  Modificar- adaptar el trabajo

•  Bajo las siguientes condiciones –  Atribución. Ud. debe atribuir el trabajo en la manera especificada por el autor o licenciante (pero de

ninguna manera que sugiera que ellos aprueban su uso del trabajo).

•  Nada de lo dispuesto en esta licencia menoscaba o restringe los derechos morales del autor.

•  Para más información ver http://creativecommons.org/licenses/by/3.0/