Cruzando el abismo educativo de la ingeniería de software utilizando Software como Servicio y...

Post on 20-Jun-2015

281 views 2 download

description

`Cruzando el abismo educativo de la ingenieria de software utilizando Software como Servicio y computación en nube' Prof. Armando Fox Facultad de Informática, Universidad de California, Berkeley fox@cs.berkeley.edu JISBD'2012 (XVII Jornadas de Ingeniería del Software y Bases de Datos) Jornadas SISTEDES 2012 (17 a 19 septiembre de 2012) Universidad de Almería

Transcript of Cruzando el abismo educativo de la ingeniería de software utilizando Software como Servicio y...

«Cruzando el Abismo Educativo»

de la Ingeniería de Software utilizando Software como Servicio (SaaS)

y Computación en Nube

Armando FoxDirector Académico de Programas

Educativos en LineaUniversidad de California, Berkeley

Sistedes 2012, Almería, España 1

La moderna ingeniería de software es…

• Más fácil y eficaz de enseñar debido a herramientas de primera clase

• Atractivo para los estudiantes y los empleadores debido a las enormes oportunidades que ofrecen las aplicaciones “cloud+client”

• Escalable a bajo costo debido a la computación en nube, ante todo la calificación automatizada desplegando esas mismas herramientas en la nube

• Nos gustaría que los demás replicaran nuestro éxito

2

Outline

• El problema y nuestra respuesta: Revisar el curso pregrado de Software Engineering

• Aprender haciendo en vez de escuchando: herramientas reemplazan metodologías

• Ampliación del curso a 50,000 estudiantes

• Aplicando la experiencia del MOOC en el aula

• Invitación: hágalo usted mismo

3

Desarrollo del software en Silicon Valley

4

• Desarrollo ágil y guiado por pruebas, programación en pareja, procesos ágiles

• Refinamiento iterativo, con despliegue frecuente, guiado por la retroalimentación del cliente

Programación en pareja en Pivotal Labs, San Francisco, CA. Foto: Tonia Fox

El problema…

• El curso Software Engineering tenía reputación floja– Estudiantes: «Nos explican las

metodologías, pero no las aplicamos en proyectos reales»

– Instructores: «Los estudiantes no aplican lo que le enseñamos»

– Empleadores: «Los estudiantes saben programar, pero les faltan habilidades importantes para el desarrollo del software…»

1. Manejar codigo heredado2. Trabajar en equipo y tratar con clientes

no técnicos 3. Automatizar las pruebas de software

* Unanimously #1 among 6 leading software companies we asked

6

Las restricciones

• El estudiante tipico le dedica 12 horas/semana a cada curso– Curso 15 semanas = 3 semanas de empleo a

tiempo completo• Para realizar aplicaciones prototipicas en solo

14 semanas, hay que proporcionarles herramientas de alta productividad

• El futuro del software incluirá computación tanto en la nube como en el cliente móvil…¿cuál escoger?

• El entorno Rails para desplegar aplicaciones Ruby en la nube dispone de las mejores herramientas

7

?

Revisar el curso

• El contenido y los temas del curso deben ser revisados por comites de la Universidad y también externos a la Universidad

• Pero el profesor tiene discreción en como presentar los temas

8

Requisitos y documentación

Mantenimiento y refactorización

Disenõ y construcción Modelos de desarrollo

Arquitectura del software

Pruebas de software

Métricas de calidad Entregue y despliegue

9

Las revisiones

• Enseñanza de los temas utilizando Rails, un entorno de alta productividad para el SaaS

• Aprender haciendo: herramientas reemplazan metodologías

• Enseñar y aprovecharse del Cloud Computing

• Equipos compactos y desarrollo ágil (ideal para el aula)

• Énfasis en pruebas

Una iteración de 2 semanas

10

Discutir con cliente

Prototipo de baja fidelidad

Historias de usuario

Behavior-driven Design (BDD)

RSpecTest-driven development

(TDD) para pruebas unitarias

Medir velocidad

Desplegar en la nube

Codigo heredado

Patrones de diseño

Diseño impulsado por comportamiento

Desarrollo dirigido por pruebas

Outline

• El problema y nuestra respuesta: Revisar el curso pregrado de Software Engineering

• Aprender haciendo en vez de escuchando: herramientas reemplazan metodologías

• Ampliación del curso a 50,000 estudiantes

• Aplicando la experiencia del MOOC en el aula

• Invitación: hágalo usted mismo

11

Metodologías y temas…

• Arquitectura del software, patrones de diseño, practicas de programación

• Test-first development, pruebas unitarias

• Behavior-driven design, pruebas de integración y aceptación

• Gestión ágil basada en iteraciones

• Colaboración en el equipo «dos pizzas» en gestión del codigo fuente

• Despliegue SaaS, seguridad, prestaciones

• Ruby & Rails

• RSpec

• Cucumber

• Pivotal Tracker• Git & GitHub

• Amazon EC2, Heroku

12

…reforzados por herramientas

13

Ejemplo: BDD con prototipo de baja fidelidad

Llegar al acuerdo con el cliente: historias de usuario

Característica: Ajustar a mano el horario del día Como personal del depto. EECS Para poder acomodar cambios a ultima hora Quiero poder ajustar las citas a mano

Escenario: añadir candidato a cita con capacidad disponible Dado que "Velvel Kahan" está disponible a las 10:20 Cuando elijo "Velvel Kahan" del menu de la cita

10:20 con "Armando Fox" Y pulso "Save Changes" Entonces veré la pagina del horario maestro Y veré el texto "Velvel Kahan añadido a la cita 10:20" Y "Armando Fox" tendrá cita con "Velvel Kahan"

a las 10:20 Escenario: quitar candidato de una cita

...etc.14

Conviertiendo historias en pruebas de

aceptación• Herramienta que ejecuta historias «en

texto plano» como pruebas de integración y aceptación

• Cada escenario corresponde a una historia de usuario– Pasos Dado establecen precondiciones– Pasos Cuando simulan las acciones del

usuario con simulador de navegador o bien con Selenium

– Pasos Entonces verifican las aserciónes • Definiciones de los pasos unen cada

línea de la historia a un trozo de código que realiza el intento del paso

• Notamos funcionamiento y cobertura de las pruebas

15

Despliegue     

• «Plataforma como servicio» (PaaS) que se encarga de los detalles mecánicos del despliegue– Nivel de servicio gratuito basta para estos

proyectos• Despliegue sencillo = despliegue

frecuente– El cliente revisa las nuevas características

desplegadas durante cada iteración• Retroalimentación del cliente guía el

esfuerzo de la siguiente iteración 16

19

De metodologías a herramientas

• Los estudiantes pueden seguir nuestros consejos (metodologías) con más facilidad

• Los instructores pueden observer y basar la calificación en medidas cuantitativas, y comprender más rápidamente el alcance de cada proyecto

• El progreso del equipo puede ser cuantificado a través de varias iteraciones

• Los estudiantes reciben retroalimentación inmediata indicando si sus estimados fueron realisticas, y ajustan para la proxima iteración

Resultados y Observaciones

• Matriculación en el curso: 35 – 50 – 75 – 110 – 165

• Comentarios de los clientes (25 empresas sin fines de lucro)– 92% “contentos” o “ecstáticos” – 48% le ofrecieron empleo continuado a los

estudiantes – 67% de los equipos tienen intención de

mantener las aplicaciones, aún sin oferta de empleo

• ¡Los estudiantes realmente se ingresan en el proceso ágil! – La complejidad de las historias se nivela en las

últimas iteraciones – Los proyectos varían en alcance, pero apenas en

la calidad del código y de las pruebas • El 60% de los estudiantes opinan que

debemos hacer todo lo posible para ampliar la matriculación en este curso

20

Algunos ejemplos de proyectos

21

Outline

• El problema y nuestra respuesta: Revisar el curso pregrado de Software Engineering

• Aprender haciendo en vez de escuchando: herramientas reemplazan metodologías

• Ampliación del curso a 50,000 estudiantes

• Aplicando la experiencia del MOOC en el aula

• Invitación: hágalo usted mismo

22

Cambios para el MOOC

• Calificadores automatizados sofisticados para tareas de programación (código abierto en GitHub)

• Subdivisión de las conferencias en módulos de 7-10 minutos con preguntas de autoevaluación

• Sin cambio: mismas tareas, exámenes, fechas topes

• Costo directo de calificación automatizada en la nube, descargo del imagen VM, etc.: <$5/estudiante– subvencionado por donaciones de

Amazon, GitHub, Google, Microsoft

24

Una iteración de 2 semanas

25

Discutir con cliente

Prototipo de baja fidelidad

Historias del usuario

Behavior-driven Design (BDD)

RSpecTest-driven development

(TDD) para pruebas unitarias

Medir velocidad

Desplegar en la nube

Código heredado

Patrones de diseño

MO

OC

Calificación Automatizada

26

Entrega de la tarea

Estrategia de calificación

Subir ficheras de código

• pruebas RSpec (funcionamiento)• [luego] reek/flay (estilo)

Subir ficheras con pruebas

• Prueba por mutación (Amman & Offutt): inyectar errores en la aplicación, verificar que no pasan las pruebas

Ingresar URL de aplicación desplegada en la nube (Heroku)

• Prueba remota con RSpec, Cucumber, y Mechanize, también en la nube• [luego] prueba remota con SauceLabs

Preguntas cortas (opción múltiple, etc.)

• Herramientas que emiten formato XML e impresa

Califica-dor

presenta-

ción del estudi-ante

rúbrica

retroalimentación

95100

1950 1955 1960 1965 1970 1975 1980 1985 1990 1995 20000.0%

5.0%

10.0%

15.0%

20.0%

25.0%

30.0%

35.0%

0% 1% 2% 3%4%

8%

15%

28%32%

7%

0%

Fecha de nacimiento

¿Quiénes son los estudiantes?

• 12% fem., 88% masc.• Edad mediana: 27 años• 75% entre 21 y 38 años• De 10 á 106 años

33% título de pos-grado

31% título de grado

12% título grado en progreso o no

completo

8% es-cuela se-cunda-

ria12% título profe-

sional

¿Quiénes son los estudiantes?

• 75% título grado o superior; 7% instructores

• 60% tratan con desarrollo o mantenimientodel SW en el empleo

Estudiantes capaces y con altas esperanzas

¿De dónde son?

1. EE.UU.22.8%

2. India 6.6% 3. Fed. Rusa 6.6% 4. España 5.0% 5. Ucrania 4.7% 6. Brasil 4.1% 7. Colombia 3.4% 8. Canada 2.7% 9. Reino Unido 2.1% 10.Alemania 1.8%

11.Italia 1.7% 12.Polonia 1.7% 13.Romania 1.7% 14.China 1.4% 15.Argentina 1.3% 16.Belarus 1.3% 17.México 1.3%18.Pakistán 1.3% 19.Francia 1.2% 20.130 otros países

25%

Embudo y Estratificación

30

50,000 matriculados

25,000 vieron al menos 1 conferencia

10,000 presentaron al menos

1 tarea

3,500aprobaron

• «Quiero ayudar en el futuro»

• «Mejor que cualquier curso disponible á mi alcance»

«desgaste» de 90%+ confirmado por la experienca de 3 otros MOOCs en Stanford

y MIT

Outline

• El problema y nuestra respuesta: Revisar el curso pregrado de Software Engineering

• Aprender haciendo en vez de escuchando: herramientas reemplazan metodologías

• Ampliación del curso a 50,000 estudiantes

• Aplicando la experiencia del MOOC en el aula

• Invitación: hágalo usted mismo

31

Como el MOOC mejoró el curso residencial

• Calificación automatizada…– permite que los ayudantes de enseñanza

se enfoquen en revisar los diseños, no en calificar

– Nos exige tareas libres de errores– Notar: debido a las mismas herramientas

que motivaron nuestros revisiones del curso

• Mejor organización de las conferencias: mayor asistencia, menos alumnos distraídos

• Mínima dependencia en recursos informáticos de la Universidad (debido a la nube)

32

MOOC comparado con curso residencial

• Esfuerzo (horas/semana) y calificación de los estudiantes MOOC: dentro del 10% comparado con estudiantes en Berkeley, …pero… – No hay contacto directo entre estudiantes

MOOC y profesores/ayudantes – MOOC no exige proyecto con cliente

(profesor y ayudantes supervisan y facilitan revisión del diseño)

• Oportunidad: combinar las mejores características del MOOC con la experiencia del curso residencial

33

Desventajas/Dolores/Trampas

• Criterios de calificación son demasiado anchos o estrechos – Desarrollo de las rúbricas por ensayo y error, yá

que el MOOC lleva 4 semanas de retraso comparado con curso residencial

– Afinar la retroalimentación de los calificadores para enfocar el contexto de las pruebas que no pasan

• Imposible impedir el plagio: en curso residencial, los exámenes se toman en el aula– Tal vez no es problema mientras el MOOC no

ofrezca crédito académico• Fechas tope de los proyectos a veces no

coincidían con la disponibilidad del cliente– Estimar «velocidad» requiere múltiples medidas

consistentes

34

Outline

• El problema y nuestra respuesta: Revisar el curso pregrado de Software Engineering

• Aprender haciendo en vez de escuchando: herramientas reemplazan metodologías

• Ampliación del curso a 50,000 estudiantes

• Aplicando la experiencia del MOOC en el aula

• Invitación: hágalo usted mismo

35

Obstáculo: ¡demasiados libros!

36

Respuesta: Nuevo texto conciso y

barato

37

• Conecta los temas de acuerdo con sus funciones en una iteración ágil

• Se refiere a libros adicionales para obtener más detalles sobre cada tema

• Un capítulo = una semana• Una sección del capítulo =

un módulo de video (conferencias)

• Libro electrónico con actualizaciones gratuitas (7 veces desde primera publicación en enero)

€9.99 electrónica€19.99 impresaDescuento 20%

en CreateSpace.com

Reacciones de nuestros colegas

«Sería mucho más probable preferir alumnos de este programa que de cualquier otro que he visto.»Brad Green, Gerente de Desarrollo y de Pruebas, Google Inc.

«Es un placer ver un texto que hace hincapié en la producción de software útil y real. También aplaudo el énfasis en obtener resultados al inicio del proceso, pues nada estimula más la moral y la actividad de los estudiantes.»Frederick P. Brooks, ganador del Premio Turing y autor del libro clasico The Mythical Man-Month

38

Apoyando a los maestros

• 24 Julio: UC Berkeley se une a EdX• “SaaS parte II” a ofrecer en noviembre

– Técnicas avanzadas, trabajando en equipos «dos pizzas», manejando código heredado, JavaScript, seguridad y prestaciones en la nube

• Mejorando las evaluaciones a través de minería de datos – ¿Cuáles preguntas son las más dificiles?– ¿Cuáles son las que más discriminan entre

niveles de comprensión? 39

Programa beta:Pruebelo en su aula

• Recursos para utilizar como lo desee– Conferencias pregrabadas– Exámenes y tareas de

programación– Texto conciso y barato– Materias adicionales para

el instructor – Calificadores

automatizados compatibles con el entorno EdX (será código abierto antes del fin de año)

40

Descuento del 20% en el libro impreso e

informes sobre el programa beta

¿Qué representa SaaS+Ágil para el aula y la empresa?

• Debido a computación en la nube, el talento en desarrollo puede convertirse en recompensa rápidacon baja barrera de entrada

• Los MOOCs pueden ayudar tanto con el reclutamento y la formación continua

• Excelentes herramientas + nube + MOOC + libro= preparación de los futuros líderes del software

41

SaaS + nube

Desarrollo ágilRails

« triangul

o amoroso

»

¡Gracias!

Agradecimientos: Profs. David Patterson, Andrew Ng, Daphne Koller, Daniel Garcia, y personal de enseñanza

de CS 169 desde 2007 al presenteTraducción: es.wikipedia.org, Google Translate, y

Estudiantes Posgrados Latinoamericanos en Ingeniería y Ciencias (LAGSES) de UC Berkeley

Donaciones y/o apoyo: Amazon Web Services, GitHub, Google Inc., Microsoft Corp., New Relic, Pivotal Labs,

Sauce Labs

42