PDF de programación - Desarrollo rápido de software libre de alta calidad

Desarrollo rápido de software libre de alta calidad
Ingeniería de software asistida por computadora, enfocada en tareas, para

agilizar el ciclo de vida de las aplicaciones, mediante mejora continua

disciplinada a nivel personal

Mariano A. Reingart 

[email protected]

Universitat Oberta de Catalunya

Abstract. El presente artículo resume el estudio, desarrollo e implementación
de un marco de trabajo teórico/práctico para creación y mantenimiento ágil de
software libre, orientado al desarrollo de aplicaciones empresariales centradas
en   datos   (principalmente   transaccionales,   con   bases   de   datos   relacionales,
lenguaje de programación dinámico e interfaces web y visuales). Se analiza el
estado del arte respecto a proyectos libres y abiertos (producción por pares,
fomento,   motivación,   diversidad,   gobernanza,   calidad,   etc.)   y   se   exploran
técnicas   para   migración   de   lenguajes   legados   discontinuados   (VB   clásico,
usando técnicas EBNF). Se incluye el desarrollo de artefactos de software:
herramientas integradas para ingeniería asistida por computadora (I­CASE),
contemplando  la recolección  automática  de datos  estadísticos. Se proponen
varias mejoras al estado del arte respecto a mayor precisión en la medición de
tiempos (detección facial vía WebCam) y seguimiento de líneas de código por
identificadores globales (UUID); presentando los resultados preliminares de
una prueba piloto (experiencia personal investigación­acción), para validación
cualitativa y cuantitativa inicial, relevancia, implicaciones y trabajos futuros.

Palabras   clave:  ingeniería   de   software   libre   /   código   abierto,   métricas,
calidad, python, postgresql, web2py, wxwidgets

1 Introducción

En   el   futuro   cercano,   los   investigadores   todavía   tienen   muchas   preguntas
intrigantes que explorar: ¿Aplica la Ley de  Brooks al desarrollo de código abierto,
bajo cuales circunstancias, o por qué no? ¿Cuales son las implicancias? ¿Es el
desarrollo   de   código   abierto   una   manera   de   producir   software   mejor   y   más
eficiente, o es un enorme esfuerzo gastado invisiblemente? ¿Como podemos estimar
el esfuerzo real que se consuma en un proyecto open source, y como podemos medir
el   impacto   de   la   comunidad   rodeando   al   núcleo   de   desarrolladores?   ¿Cuales
diferencias pueden ser encontradas sobre la organización, procesos y productos, y
cómo se relacionan con el éxito del proyecto? Si consideramos que la ingeniería de

STS 2015, 2º Simposio Argentino sobre Tecnología y Sociedad.44 JAIIO - STS 2015 - ISSN: 2451-7631316 software ha estudiado el desarrollo por décadas, y que muchos proyectos aún están
experimentando problemas al punto de fracasar completamente, la ingeniería de
software open source será un tema interesante en los años venideros...

Traducido de Koch S. & Gonzalez­Barahona J. M. (2005).  Open Source
software   engineering:   The   state   of   research.   Publicado   en   “First
    Source” 1 (peer review journal on internet)
Monday
 

  #2: 
 Open
 
    Issue
 
 

 '  s     Special

 

1.1 El contexto de la ingeniería de software libre:

Esta investigación tiene como eje las propuestas de Brooks que hizo en su ensayo
“No Silver Bullets”2  acerca de si se podría encontrar una bala de plata para poder
superar la crisis del software. El autor propone:

•
•
•
•

Evitar construir lo que puede ser adquirido
Usar prototipado rápido
Hacer crecer el software orgánicamente
Desarrollar a los grandes diseñadores 

Entendiendo que el software libre presenta muchas de estas características, en base a
estos   puntos   se   realizó   el   análisis   del   estado   del   arte   para   encontrar   un   marco
metodológico y proponer una herramienta superadora.

1.2 Motivación y antecedentes

Una de los propósitos de este proyecto es aplicar los lineamientos y mejorar las
deficiencias   conocidas   del   PSP­BOK3  (Personal   Software   Process   –   Body   of
Knowledge), que junto con el Team Software Process del SEI forman un conjunto de
prácticas   disciplinadas   de   la   ingeniería   del   software.   Sus   elementos   podrían   ser
aplicables a una certificación de calidad de software CMMI nivel 5 que serían de
utilidad en ciertos contextos (por ej. la Ley 25.922 de Promoción de la Industria del
Software en Argentina).

Se exploran investigaciones modernas como el proyecto Mylyn4 (plugin para el IDE
Eclipse), y tendencias recientes Agile ALM (Application Lifecycle Management5),
que buscan integrar la gestión ágil del ciclo de vidas de las aplicaciones.

 .  org 

 /  ojs 

 /  index
 

 

 .  php 

 /  fm 

 ://   firstmonday

1   http 
 /  view 
2 http://es.wikipedia.org/wiki/No_hay_balas_de_plata 
3 http://www.sei.cmu.edu/tsp/tools/bok/ 
4 http://www.eclipse.org/mylyn/ 
5 https://en.wikipedia.org/wiki/Application_lifecycle_management 

 /1466/1381 

 /  article
 

STS 2015, 2º Simposio Argentino sobre Tecnología y Sociedad.44 JAIIO - STS 2015 - ISSN: 2451-7631317 Al   contemplar   herramientas   de   desarrollo   rápido   de   aplicaciones,   se   consideran
migraciones de lenguajes legados como Visual Basic Clásico (5, 6) / Visual FoxPro
(discontinuados   por   su   proveedor),   analizando   un   Conversor   EBNF   (Notación
Extendida Backus­Naur ISO / IEC 14977).

En artículos anteriores6  se realizó un acercamiento inicial a las las metodologías,
procesos,   herramientas,   lenguaje   de   programación   (Python),   base   de   datos
(PostgreSQL)   y   framework   web   (web2py)   y   toolkit   gráfico   (wxPython),
contemplados   en   el   presente   trabajo.   También   se   publicó   un   artículo7  sobre   el
desarrollos   del   proyecto   “PyAfipWs8”   de   software   libre   que   analiza   cuestiones
relevantes ampliadas en el presente documento.

2 Estado del arte

2.1 Modelo de Producción del Software Libre

2.1.1 Fomento y motivación de los desarrolladores:

Ciertos   estudios   (Rossi,   2006)   encuentran   que   el   software   libre   sería   superador
“homo   œconomicus”,   donde   no   sólo   se   buscaría   una   motivación   material,   sino
también   recompensas   extrínsecas:   reputación   y   reconocimiento   pares,   solución
necesidades   propias   ­scratching   an   itch­,   aprendizaje/mejoramiento   skills,   lo   que
favorecería la libre revelación de innovaciones.

Además se han encontrado motivaciones intrínsecas: diversión y autodeterminación,
que en conjunto posibilitaría una mayor diversidad para evitar la “tragedia de los
comunes9” (disputas entre personas bien intencionadas y con razonamientos lógicos
sectorizados que destruyen un bien compartido).

También existen dificultades (Feller & Fitzgeral, 2003) por un elaborado sistema de
tabúes y costumbres (normas “esotéricas”, disputas de ego, etc.) lo que conlleva a
una menor tolerancia a novatos y principiantes en las comunidades de software libre.

6 Reingart, Mariano. Plataforma de Desarrollo Rápido de Aplicaciones bajo el Proceso de
Software Personal: en búsqueda de agilidad, solidez y disciplina para la Ingeniería de
Software. 41° JAIIO ­ EST 2012 ­ ISSN: 1850­2946 – Pg. 344 ­  367
http://41jaiio.sadio.org.ar/sites/default/files/17_EST_2012.pdf 

7 Reingart, Mariano. PyAfipWs: facilitando, extendiendo y liberando los Servicios Web

de AFIP (Factura Electrónica ...) 41° JAIIO ­ JSL 2012 ­ ISSN: 1850­2857 Pg. 164­178
http://41jaiio.sadio.org.ar/sites/default/files/15_JSL_2012.pdf 

8 https://www.github.com/reingart/pyafipws 
9 https://es.wikipedia.org/wiki/Tragedia_de_los_comunes 

STS 2015, 2º Simposio Argentino sobre Tecnología y Sociedad.44 JAIIO - STS 2015 - ISSN: 2451-7631318 2.1.2 Crecimiento orgánico: modularización y gobernanza:

Siguiendo el análisis inicial (Rossi, 2006), el desarrollo de FOSS es un caso exitoso
no solo por la capacidad de atracción de programadores altamente capacitados y
motivados a lo largo del tiempo, sino también por la calidad del producto final,
rapidez de desarrollo y bajos costos. 

Si bien esta planteada la discusión sobre la caracterización “catedral vs. bazar10”
(descentralización de decisiones ex­ante, diseño concurrente, integración de usuarios,
auto­selección según habilidades), todo esto facilita un proceso desarrollo paralelo
larga   escala   vs.   el   “proceso   producción   fabril”   más   tradicional   de   la   industria
propietaria. A su vez, se aprovecha la inteligencia de la comunidad, por lo que el
ritmo de desarrollo es determinado por el miembro más productivo. Pero por otro
lado, la mayoría de los proyectos cuentan con pocos desarrolladores y el contacto
entre comunidades suele ser bajo, por lo que algunos autores lo caracterizan como
una “cueva” en vez de “comunidad” (no hay una “red plana de pares interactuando”).

También hay un división del trabajo entre contribuidores heterogéneos: núcleo de
desarrolladores, desarrolladores ocasionales y usuarios. Esto generaría la existencia
de barreras que dependen de los siguientes factores claves que deben ser superados:

•
•
•
•

la facilidad de la programación y modificación de los módulos
el grado de independencia entre los módulos
la libertad de elección del lenguaje de programación
la posibilidad de “conectar” el módulo a la arquitectura

Respecto  a  la  gobernanza,   se  encuentran  principalmente  esquemas  de   “dictadura
benevolente” o “comité de votación”, por lo que imagen anárquica del FOSS no es
adecuada: es esencial el liderazgo y autoridad (reputación, lealtad e identificación, lo
que   acompleja   la   coordinación   en   un   contexto   de   colaboración   voluntaria,
especialmente para impedir bifurcaciones y duplicación del trabajo).
Ciertos   estudios   (Holck   &   Jørgensen,   2005)   analizan   la   delegación   de
“lugartenientes”   (modularización),   pasando   de   proyectos   en   solitario   (“solo”)   a
proyectos jerarquizados con “dueños de módulos” o “mantenedores”, con el objetivo
de   balancear   anarquía   con   control:   ¿cuánta   estr