Este documento discute cuatro posibles soluciones para quien desarrollará las aplicaciones del futuro: 1) aumentar la productividad y reducir errores mediante ingeniería dirigida por modelos; 2) aprovechar al máximo la comunidad de código abierto; 3) permitir que los usuarios finales se conviertan en desarrolladores ocasionales; y 4) externalizar parte del trabajo a la inteligencia artificial.

1. Programo, luego
existo
- René Descartes

2. ¿Quién va a desarrollar las Apps del
futuro?
Jordi Cabot
@softmodeling / @ingdesoftware – jordicabot.com June 2017

3. About

4. 2 niñas
1 libro
0 árboles
180 artículos
3.5 M financiación
4 países
1 startup (A/B testing WP)
Muy pocas LOCs
Unos cuantos años
Flickr/FlazingoPhotos

5. SOM Research Lab
Software runs the world. Models run the software

6. Nuestra misión
Interested in the broad
area of systems and
software engineering,
especially promoting the
rigorous use of software
models and engineering
principles in all software
engineering tasks.
Flickr/clement127

8. Disclaimer

9. Modelas y punto!!!Cualquier parecido con la (futura)
realidad es pura coincidencia

10. “As a writer, my job is to change your
perspective and make you think
outside the box.” - Mary Sage Nguyen

12. Verdades absolutas

14. Más programadores NO es la solución

15. SW
Eng
Developer: Creates
working software
Programmer: Writes code

16. 0
10
20
30
40
50
60
Programmers (in M)
Estimated number of programmers (EEUU)
Potential amateur programmers self-declared amateur programmers PROs

17. Shallow work:
non-cognitively demanding,
logistic style task, often
performed while distracted
¿Programación = shallow work?
Escribir código es la manera
menos eficiente de produir SW

18. Solución 1: Más productividad y
menos bugs

19. Ingeniería de Software
(Dirigida por Modelos)

20. • Grady Booch – history of softwre engineering
The entire history of software engineering is that of
the rise in levels of abstraction
- Grady Booch
OBJETIVO: Escribir cada
vez menos código

21. Algo que todos hacen

22. IDM (MDE en inglés) es la formalización/culminación de este proceso

23. Model
Rapid prototyping
Static analysis
Code generation
Automated testing
Refactoring/
Transformation
Documentation
[Illustration by Bernhard Rumpe]
IDM = Modelos como parte central de la
Ingeniería del Software

24. La equación IDM:
Models +
Transformations =
Software

25. Original
model
1st
refinement
nth
refinement
Model-to-model
Transformation
Model-to-text
Transformation
...
Requirements
Use Case
Class Diagram
Java Project

26. Un modelo
26
Ciudad de Nantes = “system” a
modelar
Un mapa es de hecho un modelo
del sistema
La leyenda del mapa es la
gramática / metamodelo
Existen diferentes tipos mapas:
transporte, alcantarillado,…
que dan “vistas” diferentes de
la ciudad

27. Muy parecido al mundo de la
programación
MDE Grammarware
MOF
(metametamodel)
UML
(metamodel)
ABank.uml
EBNF.g
Java.g
MyProgram.java

28. (common-sense) code generation

29. Beneficios MDE
(bien hecho)
+productividad +calidad +Mantenimiento ….
2X – 8X 1.2X – 4X 80%

30. Y sí, se puede ser ágil y modelar

31. PERO lo lleva
diciendo desde
1985

32. Adopción MDE

33. • Asterix view : resistentes al modelado

35. To model, or not to model, this is the WRONG
question
- Shakespeare
La buena pregunta:
qué modelos, cuantos,

36. Depende del proyecto:
•Objetivo
•Tecnología
•Equipo
•Tamaño
•Dominio
Depende, de qué depende…

37. http://matt.might.net/articles/phd-school-in-pictures
Me prohibieron utilizar mis
500+ slides de “introducción
a la IDM” 

38. Solución 2: Saquemos el máximo
provecho de la comunidad

39. Tenemos que ser un poco
de «letras»

40. Your community is the
KEY

41. Code
Community

42. How to
help your
OSS
succeed
Governing
OptimizingOnboarding

44. Ponerlo en pràctica: Software Analysis

45. No se trata
de hacer
anàlisis
estático del
código

46. Optimizing:
Community Health

47. Undertanding Community = Graph Analysis
• Many types of graphs (e.g. Bipartite graphs)
• Many types of properties
– Micro-view (local properties)
– Macro-view (global properties)
– Meso-level (emerging properties)
• Analysis at different levels

49. Build the right
graph
for yourpurpose

50. Size doesn’t matter

51. Bus Factor
“Number of key developers who would need to be
incapacitated (hit by a bus), to send the project into
disarray that it would not be able to proceed”

52. 64.43%
12.58%

53. Betweenness & cia
Useful to identify
subcommunities
and increase
commnication

54. Gitana: Integrated analysis in SQL
Coding platform
Issue trackers Commun. channels
Code review tools

55. Attracting contributors
(and keeping them)

57. Facilitateon boarding: Importance of first
impressions

58. Gamificationon top of GitHub

59. What kidney
exchange
programs can
teach us about
OSS?
© www.forbes.com

60. OSS = matching market
(mercados donde el dinero
no es el factor principal)

61. © Apple Records
Governing:
Power to the people

63. La governanza de
los proyectos tiene
que ser
transparente

64. Benevolent
Dictator for Life<-
Why???

65. Los proyectos
OSS deberían
ser más
democráticos
(y no, forking
no es una
buena opción)

66. ******

67. Project myProject {
Roles: Committers
Deadlines:
myDeadline : 7 days
Rules:
myMajorityRule :
Majority {
applied to Task
when TaskReview
people Committers
range Present
minVotes 3
deadline myDeadline
}
}
All the proposals for new development tasks will be
accepted or rejected in 7 days by the committers of the
project.
Verbalization

69. Solución 3: Un usuario = un
desarrollador (ocasional)

70. Todo usuario
esconde un
programador en
su interior

72. Citizen developers

73. Citizen developers = End-User programming 2.0
¿Ahora
sí?
Demanda
PlataformasCognification

74. “the goal of the project is to
make the promise of
open data a reality by
giving non-technical
users tools they can use
to find and compose the
information they need”

75. ?
API Discovery: What APIs / open data sources?

76. ?
S1
S2
S1 S2
¿Y cómo los puedo combinar?

77. JSON Discoverer – Extracting implicit
models in JSON documents

78. JSON Discoverer

79. Open Data for All

81. Solución 4: Hacer outsourcing del
trabajo a una inteligencia externa

82. Cognification

83. Cognification:
The application of knowledge
to boost the performance
and impact of a process

84. Durante la revolución
industrial todo se
electrificó.
En la próxima todo se
“cognificará” con acceso
barato una AI especializada

85. El mejor
jugador de
ajedrez del
mundo

86. Cognification
ML
Crowdsourcing
Ontologies
Big Data
…

87. Cognifying Software Development: 5 Examples
• Estimar productividad de los programadores
• Predecir componentes que van a fallar
• Bot que facilite el modelado sugiriendo buenas prácticas y
posibles fallos en el dominio
• Model inferencer para descubrir modelos implícitos en datos
semi-estructurados
• Generador de código que pase el “test de Turing de IDM”

89. La ACM ha propuesto 7
principios para la
transparencia y
responsabilidad de los
algoritmos
RESPONSABILIDAD
Las instituciones son responsables de las decisiones tomadas por sus algoritmos,
aunque no sean capaces de explicar el cómo se ha llegado a esas decisiones

90. Conclusión

91. El “10x
programmer”
existe
… pero no es
un programador
Cualquiera de
vosotros puede serlo
con las herramientas
adecuadas

95. http://modeling-languages.com

96. http://ingenieriadesoftware.es

97. Para cualquier
cosa:
jordi.cabot@
icrea.cat
@softmodeling
@ingdesoftware