Carlos Rincón, Alfredo Acurero, David Bracho¹

¹ Todos profesores miembros de la Unidad de Redes e Ingeniería Telemática, Departamento de Computación, Facultad Experimental de Ciencias, Universidad del Zulia. Correo electrónico para correspondencia crincon@luz.edu.ve

Palabras clave: entorno de programación, programación colaborativa, aspectos de diseño

Key words: Programming Environment, Collaborative Programming, Design Aspects.

Recibido: 22-11-07 Aceptado: 28-04-08

Según Pérez (1998), los lenguajes de programación se han transformado de simples traductores a sofisticados compiladores optimizadores. La evolución de los lenguajes de programación (de bajo nivel a alto nivel), se tradujo en la masificación del proceso de programación, mejorando la calidad y tiempo de desarrollo del software.

Desde el punto de vista de la metodología de trabajo utilizada en el proceso de desarrollo de software (programación), es importante diferenciar la programación en equipo de la programación colaborativa. Para Nosek (1998), la programación en grupo significa esfuerzos coordinados de programadores individuales, quienes se dividen una tarea de programación de un sistema amplio y complejo, mientras que la programación colaborativa significa dos o más programadores trabajando conjuntamente sobre el mismo algoritmo o código.

Varios investigadores como Nawrocki y Wojciechowski (2001); Nosek (1998); Williams, Kessler, Cunningham y Jefries (2000), entre otros, confirman que mediante el uso de la programación colaborativa, se obtienen mejores resultados considerando métricas como tiempo de desarrollo y eficiencia del código desarrollado. Estos resultados fundamentan la necesidad de generación de herramientas que se fundamenten en la programación colaborativa, para el desarrollo de software.

La comunicación entre los usuarios de un entorno de programación colaborativo debe ser confiable y simple, principalmente debido a la necesidad de garantizar el intercambio de información entre los programadores sin que esto signifique una sobrecarga que influya en el rendimiento del entorno.

Según Cerami (2002), en la actualidad los servicios web se presentan como la herramienta de comunicación ideal para interconectar aplicaciones informáticas, esto basado en su simplicidad (basados en XML) y su confiabilidad. Lo antes expuesto, fundamenta la idea propuesta de utilizar los servicios web como plataforma de comunicación de los entornos de programación colaborativos, dado a que permitirá la interacción de los programadores cuyas estaciones de trabajo se encuentren conectadas a una red de datos.

La fundamentación teórica de toda investigación, es la base para la generación de conocimiento y la formulación de conclusiones y aportes relevantes. Es por ello, que se definirán algunos términos asociados con la investigación:

1. Programación par: según Nawrocki y Wojciechowski (2001), se refiere a la programación hecha por dos programadores. Mientras uno de ellos se enfoca en el código, el otro se encuentra continuamente revisando la calidad, haciendo preguntas, tratando de entender, y buscando alternativas que puedan mejorar lo realizado y evitar los defectos.

2. Programación eXtrema (XP): resalta Williams (2000), que se trata de un tipo de metodología que no tiene evidencia estadística, como lo hace el Proceso de Programación Personal (PSP), para lograr su efectividad. La efectividad en este tipo de programación, es altamente anecdótica (o basada en experiencias), pero que ha logrado llamar la atención de investigadores y consultores de ingeniería de software. Explica Williams que la XP se basa fuertemente en la programación par. Durante la programación, se realiza una revisión constante del código, orientándose a las filosofías de la remoción eficiente de la programación defectuosa, y la prevención de ella. Para la mayoría de las metodologías que se basan en XP, la acumulación de requerimientos, la localización de los recursos y las prácticas de diseño, son los aspectos más relevantes.

3. Grupos de trabajo virtuales: según Baheti, Gehringer y Stotts (2002), un grupo de trabajo virtual se refiere a un conjunto de personas que buscan un objetivo común que es el desarrollo del software, tomando en cuenta la distancia, la cultura y los límites organizacionales. En comparación con los grupos de trabajo en sitio, presenta ciertas desventajas, tales como: la comunicación entre los miembros, que suele estar limitada por factores de distancia, tiempo e infraestructura de comunicación. Asimismo, los miembros suelen no preocuparse por el resto del grupo, y el acceso a ciertos recursos u objetos es complicado.

• se puede descubrir mediante un mecanismo simple.

El proceso de descubrimiento de servicios web, es uno de los problemas principales que plantea la arquitectura orientada a servicios, debido a la heterogeneidad entre los mismos. Existen diferentes soluciones al problema del descubrimiento de servicios que son clasificadas por Garofalakis, Panagis, Sakkopoulos y Tsakalidis (2004), según el rol que desempeñe la solución:

La arquitectura de UDDI en la actualidad tiene similitud con la arquitectura utilizada para prestar el servicio de DNS (domain name server), la cual ha rendido frutos en Internet, sin embargo, el apoyo de las corporaciones de software es fundamental para permitir el crecimiento de la plataforma UDDI.

Metas y planes compartidos: donde se busca que, mientras dure la interacción entre los participantes, se logre una comunicación eficiente, se aumente el rango de planes alternativos para llevar a cabo las actividades y se mejoren los planes anteriores constantemente (tener presente las experiencias de los planes aplicados anteriormente).

Comunicación eficiente: consiste en mejorar las conversaciones hasta el punto de comunicar sólo lo que es necesario comunicar, y para ellos las metas y planes deben ser compartidos en igual medida.

Aumento del rango de planes alternativos: se refiere a que un sistema con múltiples participantes, tiene más probabilidad de generar diversidad planes, principalmente, debido a que cada participante tiene una experiencia propia; los mismos participantes podrían tener diferentes tipos de acceso o privilegios a cierta información relevante para el proyecto; y, de acuerdo a su rol dentro del grupo, pueden establecer actividades que se relacionen con las de los demás.

6. Proceso de Software Personal (PSP): Williams (2000) recalca que el PSP define un marco de trabajo para el desarrollo de software, e incluye operaciones definidas o subprocesos, y técnicas de análisis y de medición, que ayuda a los programadores a desarrollar sus propias habilidades y su rendimiento personal. Se basa en la filosofía de la revisión del diseño y del código para la eliminación de errores. Sin embargo, su mayor enfoque es hacia la prevención de los errores como factor de eficiencia: antes que corregir los errores es preferible evitarlos.

7. Proceso de Software Colaborativo (PSC): explica Williams (2000) que el PSC se basa en varios niveles (Ver Figura 1):

McDowell, Werner, Bullock y Fernald (2003) realizaron un estudio que examinó la efectividad de la programación en pareja, y cómo afectaba el rendimiento y la toma de decisiones de los estudiantes. Entre los resultados obtenidos, se encontró que este tipo de programación en particular produjo mejores programas, con soluciones confiables y se generó una motivación particular por la programación en dichos estudiantes, hasta el punto de culminar los cursos de programación introductorios que se les impartía durante el estudio (un total de cuatro cursos). Todos estos resultados fueron obtenidos en comparación con estudiantes que programaron solos. Explican los autores que lo más relevante de los resultados obtenidos, es que este tipo de técnicas puede aplicarse como una herramienta pedagógica en los cursos a todo nivel. Además, recalca que la representación femenina en las carreras de programación (al menos en los cursos aplicados para el estudio) es muy baja, lo cual propone una futura investigación, para determinar si esta técnica también puede atraer y retener el factor femenino.

Nosek (1998), realizó un estudio basado en la programación de grupos, y tomó como referencia el uso de la programación en pareja definida por Nawrocki y Wojciechowski (2001). Para ello se basó en las dos variables principales: LEGIBILIDAD, la cual se refiere al nivel de la estrategia utilizada para resolver el problema, y FUNCIONALIDAD, la cual se refiere al grado de correspondencia de la solución presentada con respecto al problema planteado. Todos los experimentos fueron realizados bajo las mismas condiciones (sistema operativo, lenguajes, entre otros) tanto para los equipos (parejas) como para los programadores individuales. Basados en la técnica estadística t-test, se obtuvo que las parejas de programadores, produjeron soluciones más legibles y funcionales que los programadores individuales. Asimismo, se confirmó que los niveles de confianza mutua (confidence, en inglés) y motivación (enjoyment, en inglés) fueron más elevados, que los mostrados por los programadores individuales. Sin embargo, aunque estadísticamente no pudo corroborarse que el tiempo promedio para presentar la solución fuera menor en el caso de la programación en pareja (debido a que no pudo medirse con exactitud el tiempo dedicado a cada tarea específica), los resultados se corresponden con ahorro de tiempo cuando se programa en pareja. En general, se confirmó que los programadores con más años de experiencia tuvieron un mejor rendimiento.

Sin embargo, destaca Nosek que muchas de las investigaciones son realizadas con estudiantes que no poseen las suficientes destrezas y habilidades, y por ello, los resultados suelen ser, a veces, alejados de la realidad. En este experimento en particular, la calidad de los resultados mostrados por programadores de experiencia, fue muy superior a la de aquellos con poca experiencia. Definitivamente, debe estudiarse más en profundidad, la relación de la programación en pareja con respecto a las ganancias o dividendos que pueda ofrecer a las organizaciones, partiendo del hecho de que los tiempos son significativamente relevantes para ser competitivos hoy. Los puntos a desarrollar: la rapidez de obtención de la solución y la calidad de lo obtenido.

Otro estudio importante, realizado por Cockburn y Williams (2000), se refiere a los costos y beneficios asociados a la programación en pareja. En dicho experimento, se determinó que la programación colaborativa mejora la calidad del diseño, reduce los riesgos, mejora las habilidades técnicas, mejora las comunicaciones del equipo de trabajo, y es significativamente mucho más motivadora que la programación individual, con respecto a un costo de tiempo de desarrollo de apenas el 15%.

Destacan Cockburn y Williams, que los grandes beneficios que aporta, son muchos mas relevantes que los costos asociados. Más específicamente, los beneficios se relacionan con la detección de errores al momento o la revisión continua del código, la tormenta de ideas produce mejor calidad de código, los programadores complementan sus conocimientos y por ende, sus niveles de aprendizaje son más elevados; cuando termina el proyecto más de una persona conoce los detalles del mismo, lo que evita la dependencia sobre una sola persona, mejora las relaciones entre los miembros del equipo y disfrutan mejor su trabajo. De este último punto, se deriva que los niveles de productividad tiendan a aumentar significativamente.

Williams y colaboradores (2000) explican en un artículo que recopila ciertas anécdotas y experiencias sobre el uso de la programación en pareja o colaborativa, los beneficios de su uso casi en todos los niveles. En primer lugar, se hace referencia a ciertas anécdotas y luego a ciertas experiencias y experimentos realizados en la Universidad de Utah que validan cuantitativamente lo obtenido a través de experiencias individuales. Un aspecto a recalcar es que generalmente en situaciones y ambientes de alto nivel de presión, los programadores individuales tienden a aplicar técnicas indisciplinadas, lo cual puede conllevar a consecuencias fatales para las organizaciones. En cambio, en la programación colaborativa la probabilidad de que ambos desvíen las técnicas es mucho menor, con lo que se garantizaría aún más la calidad del producto obtenido y la disciplina: los niveles de responsabilidad grupal son mayores a los individuales. Sin embargo, dado que los experimentos fueron realizados a nivel individual y universitario, es necesario realizarlos a niveles industriales, para corroborar los resultados y los beneficios obtenidos, de manera que contemplen el aspecto de la integración de las tareas y mayor cantidad de grupos de trabajo.

Williams (2000), realizó un estudio que formula el Proceso de Software Colaborativo (PSC), en contraste con el Proceso de Software Personal o Individual (PSP). Debido a que ambos procesos se basan en procesos repetitivos y definidos, se trató de establecer el PSP como parámetro principal para la formulación del PSC. Para ello se realizaron experimentos estadísticos para comprobar la efectividad del nuevo método (proceso). La base de los experimentos tomó en cuenta dos grupos de trabajo, los cuales aprendieron tanto PSC como PSP. Tal investigación produjo un proceso repetitivo y bien definido para la programación en parejas validando, entre otras cosas, un nivel de calidad más elevado en la programación en parejas. Se determinó además que dada la mayor calidad del trabajo colaborativo, los costos organizacionales se reducen considerablemente; y que el trabajo se disfruta más cuando se hace de forma colaborativa.

En general, se obtuvo una mejora en las habilidades para la resolución de problemas, mejores diseños, mayor aprendizaje, mayor comunicación organizacional, menores riesgos y un equipo de trabajo compenetrado. Sin embargo, y aunque estadísticamente no es significativo según Williams (2000), los tiempos para la obtención del producto final fueron mayores cuando se trabajó en parejas (15% adicional). Tendría que analizarse más a fondo si el tiempo se convierte definitivamente o no en factor determinante a la hora de comparar PSC con PSP. También se propone la validación a nivel industrial, para contrastar los resultados obtenidos empíricamente con el mundo en producción. Otro experimento interesante podría ser los efectos de la programación en grupos grandes y la eficiencia de la comunicación.

El diseño de los entornos de programación colaborativos debe fundamentarse en una metodología de trabajo en equipo que fortalezca la interacción entre los miembros del mismo, minimice el tiempo requerido para desarrollar una solución informática y maximice la eficacia en el proceso de desarrollo de la misma.

• El comprometedor: Es el líder del grupo de trabajo. Se encarga de decidir si un código sometido a su consideración pasa a ser parte de la solución informática o es devuelto para correcciones.

El proceso de entrega de código es sencillo. Los desarrolladores generan el código y lo someten a la consideración de los revisores y el comprometedor a través de la lista de correo. En este punto del proceso cualquier miembro de la lista puede revisar el código y someter comentarios. El comprometedor tiene la decisión final sobre la aceptación o modificación del código.

Construcción del proyecto de software: considerando el proyecto de software como la suma de las tareas de programación encomendadas a los usuarios del entorno, éste debe recopilar de forma automatizada todos los códigos sometidos por los programadores y revisados por sus compañeros, con la finalidad de conformar el producto final, previa evaluación definitiva realizada por el líder del proyecto de software.

Es importante resaltar que mediante estos aspectos de diseño se pretende potenciar la idea de la programación en par. Según Nawrocki y Wojciechowski (2001), la idea de la programación en par consiste en dos programadores desarrollando una misma tarea de programación, en donde un programador escribe el código mientras el otro se encarga de revisarlo y garantizar su eficiencia. Los aspectos planteados maximizan este concepto debido a que se eleva el número de programadores que revisan el código (n-1, donde n es la cantidad de programadores del entorno), ofreciendo la automatización de todo el proceso de desarrollo de software, lo que se traduce en un mejor rendimiento del equipo de desarrollo.

2. Actualización en línea de recomendaciones o correcciones realizadas por los revisores. Este proceso debe permitir al desarrollador que recibe las observaciones sobre su código, decidir si acoger dichas observaciones o debatir con el revisor las observaciones realzadas (utilizando el mecanismo de comunicación definido en el punto anterior). Considerando que el modelo seleccionado para lograr la comunicación entre procesos es el Cliente – Servidor, la tecnología a utilizar para implementar este modela serán los servicios web. La selección de los servicios web se fundamenta en su simplicidad de desarrollo y bajo costo computacional en el uso de la red.

El proceso servidor se encargará de permitir la comunicación entre los procesos clientes (tanto a nivel de usuario como a nivel de programa). Por lo antes expuesto deberá ofrecer las siguientes características:

3. Una bitácora que almacene las diferentes operaciones que se realizan sobre un código en desarrollo, con la finalidad de ofrecer al comprometedor de una herramienta para el seguimiento del proceso de desarrollo, así como ofrecer métricas que permitan a éste tomar decisiones que mejoren dicho proceso.

El entorno de programación propuesto debe ser multiplataforma (ejecutarse en sistemas operativos basados en la filosofía de software libre o propietarios), razón por lo cual se propone ser desarrollado utilizando el lenguaje de programación JAVA, que permite mediante la utilización de máquinas virtuales, ejecutar aplicaciones en múltiples plataformas. De igual forma, el desarrollo e implementación de servicios web (necesarios para establecer la comunicación entre los distintos tipos de procesos que conforman el entorno) en JAVA, presenta poca o nula complejidad.

1. Baheti, P., Gehringer, E. F., y Stotts, P. D. (2002). Exploring the efficacy of distributed pair programming. Recuperado el 16 de septiembre de 2007 del sitio web del Departamento de Ciencias de la Computación. North Carolina University: http://rockfish.cs.unc.edu/pubs/XPU2002DXP.pdf        [ Links ]

2. Cerami, E. (2002). Web Services Essentials, Distributed Applications with XML-RPC, SOAP, UDDI & WSDL. USA: Editorial O'Reilly.        [ Links ]

3. Cockburn, A. y Williams, L. (2000). The costs and benefits of pair programming. Recuperado el 16 de septiembre de 2007 del sitio web del Departamento de Ciencias de la Computación. North Carolina State University: http://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.PDF        [ Links ]

4. Garofalakis, J., Panagis, Y., Sakkopoulos, E., y Tsakalidis, A. (2004). Web service discovery mechanisms: Looking for a needle in a haystack? Hypermedia Development & Web Engineering Principles and Techniques: Put them in use. Recuperado el 15 de septiembre del 2007 del sitio web del Workshop on Web Engenniering. Santa Cruz, USA: http://www.ht04.org/workshops/WebEngineering        [ Links ]

5. Lussier, S. (2004). New tricks: How open source changed the way my team works. [Versión Electrónica]. IEEE Software, Vol: 21:Pages: 68 - 72.        [ Links ]

6. McDowell, C., Werner, L., Bullock, H. E., y Fernald, J. (2003). The impact of pair programming on student performance, perception and persistence. Recuperado el 18 de septiembre de 2007 del sitio web de la IEEE Computer Society. Washington, DC, USA: http://csdl.computer.org/dl/proceedings/icse/2003/1877/00/18770602.pdf        [ Links ]

7. Nawrocki, J. y Wojciechowski, A. (2001). Experimental evaluation of pair programming. Recuperado el 6 de septiembre del sitio web de la Universidad de Massachusetts. USA: http://www2.umassd.edu/swpi/xp/pairprogramming/Nawrocki.pdf        [ Links ]

8. Nosek, J. T. (1998). The case for collaborative programming. Commun. [Versión Electrónica] ACM, 41(3):105-108.        [ Links ]

9. Pérez-Quiñones, M. A. (1998). Teaching history of programming languages to undergraduate students. Recuperado el 18 de septiembre de 2007 del sitio web de la IEEE Computer Society. Washington, DC, USA: http://csdl.computer.org/dl/proceedings/fie/1998/4762/01/00736853.pdf        [ Links ]

10. Williams, L. (2000). The Collaborative Software Process. Recuperado el 5 de septiembre de 2007 del sitio web del Departamento de Ciencias de la Computación. The University of Utah: http://www.cs.utah.edu/~lwilliam/        [ Links ]

11. Williams, L., Kessler, R. R., Cunningham, W., y Jefries, R. (2000). Strengthening the case for pair programming. [Versión Electrónica]. IEEE Softw., 17(4):19-25.        [ Links ]