Enl@ce: Revista Venezolana de Información,                     Cómo citar el artículo (Normas APA):
            Tecnología...
Aspectos de diseño de un entorno de programación colaborativo
Carlos Rincón, Alfredo Acurero y David Bracho




Design Asp...
Enl@ce: Revista Venezolana de Información, Tecnología y Conocimiento
Año 5: No. 3, Septiembre-Diciembre 2008, pp. 11-23


...
Aspectos de diseño de un entorno de programación colaborativo
Carlos Rincón, Alfredo Acurero y David Bracho




     para ...
Enl@ce: Revista Venezolana de Información, Tecnología y Conocimiento
Año 5: No. 3, Septiembre-Diciembre 2008, pp. 11-23


...
Aspectos de diseño de un entorno de programación colaborativo
Carlos Rincón, Alfredo Acurero y David Bracho




     su ma...
Enl@ce: Revista Venezolana de Información, Tecnología y Conocimiento
Año 5: No. 3, Septiembre-Diciembre 2008, pp. 11-23


...
Aspectos de diseño de un entorno de programación colaborativo
Carlos Rincón, Alfredo Acurero y David Bracho




aunque est...
Enl@ce: Revista Venezolana de Información, Tecnología y Conocimiento
Año 5: No. 3, Septiembre-Diciembre 2008, pp. 11-23


...
Aspectos de diseño de un entorno de programación colaborativo
Carlos Rincón, Alfredo Acurero y David Bracho




sirve de b...
Enl@ce: Revista Venezolana de Información, Tecnología y Conocimiento
Año 5: No. 3, Septiembre-Diciembre 2008, pp. 11-23


...
Aspectos de diseño de un entorno de programación colaborativo
Carlos Rincón, Alfredo Acurero y David Bracho




lo antes e...
Enl@ce: Revista Venezolana de Información, Tecnología y Conocimiento
Año 5: No. 3, Septiembre-Diciembre 2008, pp. 11-23


...
Upcoming SlideShare
Loading in …5
×

Carlos Rincon, Afredo Acurero...

534 views

Published on

La programación colaborativa, o programación en par, es una de las áreas más estudiadas actualmente debido a su impacto en el proceso de desarrollo de software. El propósito de la presente investigación consistió en determinar los aspectos básicos de diseño que un entorno de programación colaborativo debe ofrecer a los desarrolladores. La metodología utilizada consistió en realizar un análisis documental sobre la propuesta de Lussier acerca de la programación
colaborativa con la finalidad de determinar los aspectos de diseño, estructura e implementación de este tipo de entornos. Como resultado se obtuvo que desde el punto de vista del diseño, la comunicación entre desarrolladores, la revisión de código y la construcción del proyecto de software son los principales aspectos a considerar, y desde el punto de vista de la implementación se propone utilizar el modelo cliente - servidor y una arquitectura multiplataforma.

Published in: Technology, Business
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
534
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
7
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Carlos Rincon, Afredo Acurero...

  1. 1. Enl@ce: Revista Venezolana de Información, Cómo citar el artículo (Normas APA): Tecnología y Conocimiento Rincón, C., Acurero, A. y Bracho, D. (2008). Aspectos de di- ISSN: 1690-7515 seño de un entorno de programación colaborativo. Depósito legal pp 200402ZU1624 Enl@ce Revista Venezolana de Información, Tecno- Año 5: No. 3, Septiembre-Diciembre 2008, pp. 11-23 logía y Conocimiento, 5 (3), 11-23 Aspectos de diseño de un entorno de programación colaborativo Carlos Rincón Alfredo Acurero David Bracho1 Resumen La programación colaborativa, o programación en par, es una de las áreas más estudiadas actualmente debido a su impacto en el proceso de desarrollo de software. El propósito de la presente investigación consistió en determinar los aspectos básicos de diseño que un entorno de programación colaborativo debe ofrecer a los desarrolladores. La metodología utilizada consistió en realizar un análisis documental sobre la propuesta de Lussier acerca de la progra- mación colaborativa con la finalidad de determinar los aspectos de diseño, estructura e implementación de este tipo de entornos. Como resultado se obtuvo que desde el punto de vista del diseño, la comunicación entre desarrolladores, la revisión de código y la construcción del proyecto de software son los principales aspectos a considerar, y desde el punto de vista de la implementación se propone utilizar el modelo cliente - servidor y una arquitectura multiplataforma. Palabras clave: entorno de programación, programación colaborativa, aspectos de diseño Recibido: 22-11-07 Aceptado: 28-04-08 Todos profesores miembros de la Unidad de Redes e Ingeniería Telemática, Departamento de Computación, Facultad Experimen- 1 tal de Ciencias, Universidad del Zulia. Correo electrónico para correspondencia crincon@luz.edu.ve 11
  2. 2. Aspectos de diseño de un entorno de programación colaborativo Carlos Rincón, Alfredo Acurero y David Bracho Design Aspects of a Collaborative Programming Environment Abstract Collaborative programming or pair programming is today one of the most studied areas, because of its impact on the software developing process. The purpose of the present investigation was to determine the basic design aspects that a collaborative programming environment must offer to developers. The methodology used was a documental review of Lussier’s work about collaborative programming, to determine the design aspects, the structure and the implementation aspects of this type of environments. As result, from the design point of view, the communication between developers, code review and the construction of software project are the basic aspects to consider, and from the implementation point of view, the use of the client - server model and a multiplatform architecture are proposed. Key words: Programming Environment, Collaborative Programming, Design Aspects Motivación como consecuencia de la evolución de los sistemas de cómputo, el proceso de desarrollo de software Desde la aparición de los sistemas informá- es independiente en gran porcentaje del hardware ticos, los seres humanos los hemos utilizado como utilizado (abstracción del hardware), lo permite una herramienta para realizar un procedimiento que este proceso sea menos complicado. de forma rápida y confiable. A la traducción de un Según Pérez (1998), los lenguajes de progra- proceso en lenguaje natural a lenguaje binario se mación se han transformado de simples traducto- le conoce como programa. El software es un pro- res a sofisticados compiladores optimizadores. La grama o conjunto de programas, que facilitan la evolución de los lenguajes de programación (de interacción entre el usuario y el hardware con la bajo nivel a alto nivel), se tradujo en la masifica- finalidad de realizar una tarea o proceso. ción del proceso de programación, mejorando la El proceso de desarrollo de software ha evo- calidad y tiempo de desarrollo del software. lucionado a la par de los sistemas informáticos. En las primeras generaciones de sistemas informáti- Desde el punto de vista de la metodología cos, el usuario debía interactuar directamente con de trabajo utilizada en el proceso de desarrollo de el hardware, haciendo el proceso de desarrollo de software (programación), es importante diferen- software complicado y dependiente del sistema de ciar la programación en equipo de la programación cómputo utilizado. Sin embargo, en la actualidad y colaborativa. Para Nosek (1998), la programación 12
  3. 3. Enl@ce: Revista Venezolana de Información, Tecnología y Conocimiento Año 5: No. 3, Septiembre-Diciembre 2008, pp. 11-23 en grupo significa esfuerzos coordinados de pro- ciones informáticas, esto basado en su simplicidad gramadores individuales, quienes se dividen una (basados en XML) y su confiabilidad. Lo antes ex- tarea de programación de un sistema amplio y puesto, fundamenta la idea propuesta de utilizar complejo, mientras que la programación colabo- los servicios web como plataforma de comunica- rativa significa dos o más programadores traba- ción de los entornos de programación colabora- jando conjuntamente sobre el mismo algoritmo o tivos, dado a que permitirá la interacción de los código. programadores cuyas estaciones de trabajo se en- cuentren conectadas a una red de datos. Varios investigadores como Nawrocki y Wojciechowski (2001); Nosek (1998); Williams, Fundamentos teóricos Kessler, Cunningham y Jefries (2000), entre otros, confirman que mediante el uso de la pro- La fundamentación teórica de toda inves- gramación colaborativa, se obtienen mejores re- tigación, es la base para la generación de conoci- sultados considerando métricas como tiempo de miento y la formulación de conclusiones y aportes desarrollo y eficiencia del código desarrollado. Es- relevantes. Es por ello, que se definirán algunos tos resultados fundamentan la necesidad de gene- términos asociados con la investigación: ración de herramientas que se fundamenten en la programación colaborativa, para el desarrollo de 1. Programación par: según Nawrocki y Wojcie- software. chowski (2001), se refiere a la programación hecha por dos programadores. Mientras uno de La comunicación entre los usuarios de un ellos se enfoca en el código, el otro se encuentra entorno de programación colaborativo debe ser continuamente revisando la calidad, haciendo confiable y simple, principalmente debido a la ne- preguntas, tratando de entender, y buscando cesidad de garantizar el intercambio de informa- alternativas que puedan mejorar lo realizado y ción entre los programadores sin que esto signifi- evitar los defectos. que una sobrecarga que influya en el rendimiento del entorno. Asimismo, destacan Nawrocki y Wojciechows- ki (2001), que ambos programadores se inter- La mayoría de los entornos de programa- cambian los roles cada cierto tiempo. La Pro- ción distribuidos se basan en métodos de comu- gramación Par es considerada como una de nicación propietarios, lo que se traduce en la in- las doce prácticas de la llamada Programación capacidad de los mismos para interactuar entre sí, eXtrema(XP). aunado a la complejidad implícita en la utilización de protocolos binarios. 2. Programación eXtrema (XP): resalta Williams Según Cerami (2002), en la actualidad los (2000), que se trata de un tipo de metodología servicios web se presentan como la herramienta que no tiene evidencia estadística, como lo hace de comunicación ideal para interconectar aplica- el Proceso de Programación Personal (PSP), 13
  4. 4. Aspectos de diseño de un entorno de programación colaborativo Carlos Rincón, Alfredo Acurero y David Bracho para lograr su efectividad. La efectividad en este • no está atado a un sistema operativo o len- tipo de programación, es altamente anecdótica guaje de programación específico, (o basada en experiencias), pero que ha logrado • se autodescribe mediante gramática XML llamar la atención de investigadores y consulto- (Web Service Definition Languaje - WSDL) res de ingeniería de software. Explica Williams y, que la XP se basa fuertemente en la programa- • se puede descubrir mediante un mecanismo ción par. Durante la programación, se realiza simple. una revisión constante del código, orientándo- se a las filosofías de la remoción eficiente de la El proceso de descubrimiento de servicios programación defectuosa, y la prevención de web, es uno de los problemas principales que plan- ella. Para la mayoría de las metodologías que se tea la arquitectura orientada a servicios, debido a basan en XP, la acumulación de requerimien- la heterogeneidad entre los mismos. Existen dife- tos, la localización de los recursos y las prácticas rentes soluciones al problema del descubrimiento de diseño, son los aspectos más relevantes. de servicios que son clasificadas por Garofalakis, Panagis, Sakkopoulos y Tsakalidis (2004), según 3. Grupos de trabajo virtuales: según Baheti, Ge- el rol que desempeñe la solución: hringer y Stotts (2002), un grupo de trabajo virtual se refiere a un conjunto de personas que Rol en el proceso de descubrimiento: buscan un objetivo común que es el desarrollo del software, tomando en cuenta la distancia, Catálogos: la cultura y los límites organizacionales. En Los catálogos de servicios web son la base tec- comparación con los grupos de trabajo en si- nológica predominante para los mecanismos tio, presenta ciertas desventajas, tales como: la de descubrimiento de servicios. Son reposito- comunicación entre los miembros, que suele rios especializados que contienen la informa- estar limitada por factores de distancia, tiempo ción sobre un grupo de servicios web. El princi- e infraestructura de comunicación. Asimismo, pal mecanismo de descubrimiento de servicios los miembros suelen no preocuparse por el res- web mediante catálogos es UDDI (universal to del grupo, y el acceso a ciertos recursos u ob- description, discovery and integration). UDDI jetos es complicado. normalmente es descrita como las páginas 4. Servicios WEB: Según Cerami (2002), un ser- amarillas de los servicios web, que contiene vicio web es un servicio que: la información sobre los fabricantes de servi- cios, sus direcciones de contacto, la lista de los • Está disponible en Internet o en una red pri- servicios que estos ofrecen, las direcciones de vada (intranet), los servicios web, las interfaces de los servicios • usa el sistema de mensajería ya estandariza- web, entre otros. do XML, 14
  5. 5. Enl@ce: Revista Venezolana de Información, Tecnología y Conocimiento Año 5: No. 3, Septiembre-Diciembre 2008, pp. 11-23 El principal problema de UDDI (y de los catá- para llevar a cabo las actividades y se mejoren logos), es que está basado en una arquitectura los planes anteriores constantemente (tener centralizada, lo que se traduce en problemas presente las experiencias de los planes aplica- de congestionamiento (a medida que aumente dos anteriormente). el uso de los servicios web) y el problema del Comunicación eficiente: consiste en mejorar único punto de fallo, es decir, si el repositorio las conversaciones hasta el punto de comuni- falla, se pierde la capacidad de descubrimiento car sólo lo que es necesario comunicar, y para de servicios web. ellos las metas y planes deben ser compartidos La arquitectura de UDDI en la actualidad tie- en igual medida. ne similitud con la arquitectura utilizada para Aumento del rango de planes alternativos: se prestar el servicio de DNS (domain name refiere a que un sistema con múltiples partici- server), la cual ha rendido frutos en Internet, pantes, tiene más probabilidad de generar di- sin embargo, el apoyo de las corporaciones de versidad planes, principalmente, debido a que software es fundamental para permitir el creci- cada participante tiene una experiencia propia; miento de la plataforma UDDI. los mismos participantes podrían tener diferen- Soluciones Punto a Punto (P2P): tes tipos de acceso o privilegios a cierta informa- ción relevante para el proyecto; y, de acuerdo a La arquitectura P2P provee una plataforma su rol dentro del grupo, pueden establecer acti- para el enrutamiento y localización de infor- vidades que se relacionen con las de los demás. mación de forma descentralizada, donde cada punto provee el servicio de localización y ade- Tener presentes las experiencias de los planes más actúa como servidor de acceso a los ser- implementados anteriormente: generalmen- vicios. La utilización del modelo distribuido, te es útil en los casos en que se presente una evita los problemas planteados en el modelo situación que haya sido tratada en ocasiones centralizado, pero presenta la complicación de anteriores, y pudiera tomarse esa experiencia la transmisión de la información a todos los (buena o mala) para enrumbar el plan actual. usuarios del la red P2P. 6. Proceso de Software Personal (PSP): Williams 5. Conocimiento distribuido: Según Williams (2000) recalca que el PSP define un marco de (2000) el conocimiento distribuido es un cam- trabajo para el desarrollo de software, e incluye po de la ciencia cognitiva, que se basa en los operaciones definidas o subprocesos, y técni- siguientes puntos: cas de análisis y de medición, que ayuda a los programadores a desarrollar sus propias habi- Metas y planes compartidos: donde se busca lidades y su rendimiento personal. Se basa en que, mientras dure la interacción entre los par- la filosofía de la revisión del diseño y del código ticipantes, se logre una comunicación eficien- para la eliminación de errores. Sin embargo, te, se aumente el rango de planes alternativos 15
  6. 6. Aspectos de diseño de un entorno de programación colaborativo Carlos Rincón, Alfredo Acurero y David Bracho su mayor enfoque es hacia la prevención de los 7. Proceso de Software Colaborativo (PSC): expli- errores como factor de eficiencia: antes que co- ca Williams (2000) que el PSC se basa en va- rregir los errores es preferible evitarlos. rios niveles (Ver Figura 1): Figura 1 Proceso de Software Colaborativo Level CSP Baseline 0.0 Baseline / Current process 0.1 Coding standard Size measurement Quality Management Process improvement plan 1.0 Analysis (Use Case) CRC Card Design Brainstorming Design 1.1 Code review < Design reviews Project Management Testing Measurements 2.0 Size estimating < Resource estimating 2.1 Task planning Schedule planning Fuente: Williams (2000) • Nivel 0.0: los programadores utilizan su con entender el problema, dar respuestas a proceso natural y no recomiendan o impo- las preguntas más relevantes y estar sinto- nen ningún otro proceso adicional. Este ni- nía con las metas. vel sirve de línea base para el proceso, o se • Nivel 1.1.: en este nivel se realiza la revisión comienza desde el proceso actual. del código y del diseño, se incluye una etapa de pruebas (se aplican las técnicas de la caja • Nivel 0.1: se realizan varias mejoras peque- negra, caja blanca y regresión automática) ñas a los procesos descritos, y se comienza a y, por último, la medición de la efectividad utilizar una codificación estándar. de la calidad obtenida, con los datos que han • Nivel 1.0.: se basa en el análisis y el diseño. sido registrados desde fases o experiencias Específicamente, el análisis tiene que ver anteriores. 16
  7. 7. Enl@ce: Revista Venezolana de Información, Tecnología y Conocimiento Año 5: No. 3, Septiembre-Diciembre 2008, pp. 11-23 • Nivel 2.0.: este nivel se relaciona con la punto de culminar los cursos de programación in- gestión del proyecto, enmarcada por la es- troductorios que se les impartía durante el estudio timación del tamaño del producto y de los (un total de cuatro cursos). Todos estos resultados recursos. Para ello se utiliza un análisis de fueron obtenidos en comparación con estudiantes la regresión lineal estadística sobre una base que programaron solos. Explican los autores que de datos histórica sobre proyectos pasados. lo más relevante de los resultados obtenidos, es que este tipo de técnicas puede aplicarse como una • Nivel 2.1.: el último nivel se refiere a la plani- herramienta pedagógica en los cursos a todo nivel. ficación de tareas necesarias para culminar Además, recalca que la representación femenina el proyecto, y el tiempo que se ha empleado en las carreras de programación (al menos en los en cada tarea. Para ello se toma como tiem- cursos aplicados para el estudio) es muy baja, lo po base, el comienzo en el nivel 0.0. cual propone una futura investigación, para deter- minar si esta técnica también puede atraer y rete- Algunos antecedentes ner el factor femenino. Varios autores han analizado algunos as- Nosek (1998), realizó un estudio basado en pectos de la programación en entornos avanzados. la programación de grupos, y tomó como referen- A continuación se presentan algunas de las inves- cia el uso de la programación en pareja definida tigaciones más relevantes, que sirven como base al por Nawrocki y Wojciechowski (2001). Para ello presente trabajo: se basó en las dos variables principales: LEGIBI- LIDAD, la cual se refiere al nivel de la estrategia Según Nawrocki y Wojciechowski (2001), la utilizada para resolver el problema, y FUNCIONA- programación en entornos avanzados ha sido rela- LIDAD, la cual se refiere al grado de correspon- cionada por muchos con la llamada programación dencia de la solución presentada con respecto al en pareja (o programación colaborativa donde dos problema planteado. Todos los experimentos fue- personas trabajan al mismo tiempo, en el mismo ron realizados bajo las mismas condiciones (sis- programa. tema operativo, lenguajes, entre otros) tanto para McDowell, Werner, Bullock y Fernald los equipos (parejas) como para los programado- (2003) realizaron un estudio que examinó la efec- res individuales. Basados en la técnica estadística tividad de la programación en pareja, y cómo afec- t-test, se obtuvo que las parejas de programadores, taba el rendimiento y la toma de decisiones de los produjeron soluciones más legibles y funcionales estudiantes. Entre los resultados obtenidos, se en- que los programadores individuales. Asimismo, contró que este tipo de programación en particular se confirmó que los niveles de confianza mutua produjo mejores programas, con soluciones con- (confidence, en inglés) y motivación (enjoyment, fiables y se generó una motivación particular por en inglés) fueron más elevados, que los mostrados la programación en dichos estudiantes, hasta el por los programadores individuales. Sin embargo, 17
  8. 8. Aspectos de diseño de un entorno de programación colaborativo Carlos Rincón, Alfredo Acurero y David Bracho aunque estadísticamente no pudo corroborarse Destacan Cockburn y Williams, que los que el tiempo promedio para presentar la solución grandes beneficios que aporta, son muchos mas fuera menor en el caso de la programación en pa- relevantes que los costos asociados. Más específi- reja (debido a que no pudo medirse con exactitud camente, los beneficios se relacionan con la detec- el tiempo dedicado a cada tarea específica), los ción de errores al momento o la revisión continua resultados se corresponden con ahorro de tiem- del código, la tormenta de ideas produce mejor po cuando se programa en pareja. En general, se calidad de código, los programadores comple- confirmó que los programadores con más años de mentan sus conocimientos y por ende, sus niveles experiencia tuvieron un mejor rendimiento. de aprendizaje son más elevados; cuando termina el proyecto más de una persona conoce los deta- Sin embargo, destaca Nosek que muchas de lles del mismo, lo que evita la dependencia sobre las investigaciones son realizadas con estudiantes una sola persona, mejora las relaciones entre los que no poseen las suficientes destrezas y habilida- miembros del equipo y disfrutan mejor su trabajo. des, y por ello, los resultados suelen ser, a veces, De este último punto, se deriva que los niveles de alejados de la realidad. En este experimento en productividad tiendan a aumentar significativa- particular, la calidad de los resultados mostrados mente. por programadores de experiencia, fue muy supe- rior a la de aquellos con poca experiencia. Definiti- Williams y colaboradores (2000) explican vamente, debe estudiarse más en profundidad, la en un artículo que recopila ciertas anécdotas y relación de la programación en pareja con respec- experiencias sobre el uso de la programación en to a las ganancias o dividendos que pueda ofrecer pareja o colaborativa, los beneficios de su uso casi a las organizaciones, partiendo del hecho de que en todos los niveles. En primer lugar, se hace re- los tiempos son significativamente relevantes para ferencia a ciertas anécdotas y luego a ciertas ex- ser competitivos hoy. Los puntos a desarrollar: la periencias y experimentos realizados en la Uni- rapidez de obtención de la solución y la calidad de versidad de Utah que validan cuantitativamente lo obtenido. lo obtenido a través de experiencias individuales. Un aspecto a recalcar es que generalmente en si- Otro estudio importante, realizado por Coc- tuaciones y ambientes de alto nivel de presión, kburn y Williams (2000), se refiere a los costos y los programadores individuales tienden a aplicar beneficios asociados a la programación en pareja. técnicas indisciplinadas, lo cual puede conllevar En dicho experimento, se determinó que la progra- a consecuencias fatales para las organizaciones. mación colaborativa mejora la calidad del diseño, En cambio, en la programación colaborativa la reduce los riesgos, mejora las habilidades técnicas, probabilidad de que ambos desvíen las técnicas es mejora las comunicaciones del equipo de trabajo, mucho menor, con lo que se garantizaría aún más y es significativamente mucho más motivadora la calidad del producto obtenido y la disciplina: que la programación individual, con respecto a un los niveles de responsabilidad grupal son mayo- costo de tiempo de desarrollo de apenas el 15%. 18
  9. 9. Enl@ce: Revista Venezolana de Información, Tecnología y Conocimiento Año 5: No. 3, Septiembre-Diciembre 2008, pp. 11-23 res a los individuales. Sin embargo, dado que los jas (15% adicional). Tendría que analizarse más a experimentos fueron realizados a nivel individual fondo si el tiempo se convierte definitivamente o y universitario, es necesario realizarlos a niveles no en factor determinante a la hora de comparar industriales, para corroborar los resultados y los PSC con PSP. También se propone la validación a beneficios obtenidos, de manera que contemplen nivel industrial, para contrastar los resultados ob- el aspecto de la integración de las tareas y mayor tenidos empíricamente con el mundo en produc- cantidad de grupos de trabajo. ción. Otro experimento interesante podría ser los efectos de la programación en grupos grandes y la Williams (2000), realizó un estudio que for- eficiencia de la comunicación. mula el Proceso de Software Colaborativo (PSC), en contraste con el Proceso de Software Personal o También propone Williams que la teoría Individual (PSP). Debido a que ambos procesos se sobre el área del conocimiento distribuido y la basan en procesos repetitivos y definidos, se tra- ciencia cognitiva, debe estudiarse más a fondo en tó de establecer el PSP como parámetro principal la programación colaborativa. Asimismo, la cola- para la formulación del PSC. Para ello se realiza- boración distribuida debe explotarse a profundi- ron experimentos estadísticos para comprobar la dad, debido a que el problema de programación efectividad del nuevo método (proceso). La base colaborativa remota se incrementa con las distan- de los experimentos tomó en cuenta dos grupos cias geográficas, la plataforma de comunicación, e de trabajo, los cuales aprendieron tanto PSC como inclusive, el idioma. Por último, se propone orien- PSP. Tal investigación produjo un proceso repeti- tar otras investigaciones hacia el reconocimiento tivo y bien definido para la programación en pa- y aislamiento de los factores que afectan positi- rejas validando, entre otras cosas, un nivel de ca- vamente la llamada programación extrema (XP), lidad más elevado en la programación en parejas. debido a que no es sencillo identificarlos. Se determinó además que dada la mayor calidad del trabajo colaborativo, los costos organizaciona- Aporte les se reducen considerablemente; y que el trabajo se disfruta más cuando se hace de forma colabo- El diseño de los entornos de programación rativa. colaborativos debe fundamentarse en una meto- dología de trabajo en equipo que fortalezca la inte- En general, se obtuvo una mejora en las ha- racción entre los miembros del mismo, minimice bilidades para la resolución de problemas, mejores el tiempo requerido para desarrollar una solución diseños, mayor aprendizaje, mayor comunicación informática y maximice la eficacia en el proceso de organizacional, menores riesgos y un equipo de desarrollo de la misma. trabajo compenetrado. Sin embargo, y aunque es- tadísticamente no es significativo según Williams Lussier (2004), presenta la metodología de (2000), los tiempos para la obtención del produc- trabajo del grupo de desarrolladores del proyecto to final fueron mayores cuando se trabajó en pare- de software libre WINE (API de Windows), la cual 19
  10. 10. Aspectos de diseño de un entorno de programación colaborativo Carlos Rincón, Alfredo Acurero y David Bracho sirve de base para generar los aspectos de diseño en relación a la metodología basada en organigra- propuestos para los futuros entornos de progra- mas jerárquicos, utilizados comúnmente por las mación colaborativos: compañías desarrolladoras de software propietario. Analizando el proceso explicado por Lus- Roles en el grupo de trabajo: sier y considerando los resultados obtenidos por • Los desarrolladores: Son los encargados de éste, se proponen unos aspectos de diseño para los programar la solución informática. Escogen entornos de programación colaborativos basados las tareas de programación a desarrollar ba- en la optimización de este proceso, considerando sados en una lista de tareas por realizar es- la automatización como factor fundamental. pecificada para el grupo. Aspectos de diseño: • Los revisores: Cuando un desarrollador en- Comunicación entre Desarrolladores: el vía su código a la lista de correo, cualquier entorno de programación debe ofrecer un meca- desarrollador puede criticarlo, encontrando nismo automatizado para la interacción entre los errores y haciendo sugerencias, sin embargo desarrolladores. Soluciones como listas de correo es el desarrollador del código el responsable son consideradas como elementos externos al en- de hacer los cambios. torno, por lo que se propone un mecanismo de • El comprometedor: Es el líder del grupo de comunicación propio del entorno basado en ser- trabajo. Se encarga de decidir si un código vicios web. La utilización de servicios web facili- sometido a su consideración pasa a ser parte ta la interrelación entre los usuarios del entorno, de la solución informática o es devuelto para permitiendo la comunicación entre éstos, desde correcciones. cualquier parte del mundo. Procedimiento del grupo de trabajo: Revisión de código: mediante la comunica- El proceso de entrega de código es sencillo. Los ción ofrecida por los servicios web, los desarrolla- desarrolladores generan el código y lo someten dores deben, además de realizar la tarea de pro- a la consideración de los revisores y el compro- gramación, evaluar el código sometido por otros metedor a través de la lista de correo. En este programadores para su evaluación. Mediante este punto del proceso cualquier miembro de la lista proceso, los usuarios que evalúen el código podrán puede revisar el código y someter comentarios. emitir sugerencias al programador del código. El comprometedor tiene la decisión final sobre Construcción del proyecto de software: con- la aceptación o modificación del código. siderando el proyecto de software como la suma El resultado de la investigación de Lussier, de las tareas de programación encomendadas a los determinó que la metodología utilizada por el gru- usuarios del entorno, éste debe recopilar de forma po de desarrolladores del proyecto WINE, mejora el automatizada todos los códigos sometidos por los rendimiento del proceso de desarrollo de software programadores y revisados por sus compañeros, 20
  11. 11. Enl@ce: Revista Venezolana de Información, Tecnología y Conocimiento Año 5: No. 3, Septiembre-Diciembre 2008, pp. 11-23 con la finalidad de conformar el producto final, 1. Un mecanismo de comunicación orientado a previa evaluación definitiva realizada por el líder la conexión como la mensajería instantánea, del proyecto de software. que permita a los programadores tener una re- lación directa buscando con esto minimizar el Es importante resaltar que mediante estos tiempo de desarrollo de las soluciones. aspectos de diseño se pretende potenciar la idea 2. Actualización en línea de recomendaciones o de la programación en par. Según Nawrocki y Wo- correcciones realizadas por los revisores. Este jciechowski (2001), la idea de la programación en proceso debe permitir al desarrollador que re- par consiste en dos programadores desarrollando cibe las observaciones sobre su código, decidir una misma tarea de programación, en donde un si acoger dichas observaciones o debatir con el programador escribe el código mientras el otro revisor las observaciones realzadas (utilizando se encarga de revisarlo y garantizar su eficiencia. el mecanismo de comunicación definido en el Los aspectos planteados maximizan este concepto punto anterior). Considerando que el modelo debido a que se eleva el número de programado- seleccionado para lograr la comunicación entre res que revisan el código (n-1, donde n es la can- procesos es el Cliente – Servidor, la tecnología tidad de programadores del entorno), ofreciendo a utilizar para implementar este modela serán la automatización de todo el proceso de desarrollo los servicios web. La selección de los servicios de software, lo que se traduce en un mejor rendi- web se fundamenta en su simplicidad de desa- miento del equipo de desarrollo. rrollo y bajo costo computacional en el uso de Características del entorno de programa- la red. ción colaborativo 3. Rutinas para la evaluación de código de otros desarrolladores, mediante las cuales el de- El entorno a desarrollar estará fundamenta- sarrollador pueda proponer correcciones u do en el modelo Cliente-Servidor, por lo que cons- observaciones a los códigos presentados por tará de 2 tipos de procesos, los clientes y el servi- otros desarrolladores. Estas rutinas deberán dor. La selección de este modelo se fundamenta en permitir que las correcciones u observaciones la necesidad de ofrecer una solución informática a se realicen en tiempo real para garantizar así el los desarrolladores que consuma la menor canti- efecto que se desea lograr con la implementa- dad de recursos computacionales. ción de la metodología de desarrollo propuesta por Lussier. Los procesos Clientes: El proceso Servidor: Será el proceso que permitirá al desarrolla- El proceso servidor se encargará de permitir dor generar los programas (editor + compilador la comunicación entre los procesos clientes (tanto + enlazador), utilizando los recursos locales. Ade- a nivel de usuario como a nivel de programa). Por más ofrecerá las siguientes características: 21
  12. 12. Aspectos de diseño de un entorno de programación colaborativo Carlos Rincón, Alfredo Acurero y David Bracho lo antes expuesto deberá ofrecer las siguientes ca- Bibliografía racterísticas: Baheti, P., Gehringer, E. F., y Stotts, P. D. (2002). Explo- 1. Un mecanismo de validación de usuarios que ring the efficacy of distributed pair program- permita al entorno conocer la ubicación (a ni- ming. Recuperado el 16 de septiembre de 2007 vel de red) y estado (activo o inactivo) de los del sitio web del Departamento de Ciencias de la desarrolladores. Este mecanismo facilitará las Computación. North Carolina University: http:// tareas que tienen los procesos clientes que es- rockfish.cs.unc.edu/pubs/XPU2002DXP.pdf. tén directamente relacionadas con el uso de la Cerami, E. (2002). Web Services Essentials, Distribu- red. ted Applications with XML-RPC, SOAP, UDDI & WSDL. USA: Editorial O'Reilly. 2. Una aplicación de control de versiones que garantice el proceso de desarrollo de software Cockburn, A. y Williams, L. (2000). The costs and be- nefits of pair programming. Recuperado el 16 y minimice el trabajo que debe desarrollar el de septiembre de 2007 del sitio web del Depar- comprometedor al momento de hacer pública tamento de Ciencias de la Computación. North una nueva versión de una aplicación desarro- Carolina State University: http://collaboration. llada en el entorno. csc.ncsu.edu/laurie/Papers/XPSardinia.PDF 3. Una bitácora que almacene las diferentes ope- Garofalakis, J., Panagis, Y., Sakkopoulos, E., y Tsaka- raciones que se realizan sobre un código en lidis, A. (2004). Web service discovery mecha- desarrollo, con la finalidad de ofrecer al com- nisms: Looking for a needle in a haystack? prometedor de una herramienta para el se- Hypermedia Development & Web Engineering guimiento del proceso de desarrollo, así como Principles and Techniques: Put them in use. Re- cuperado el 15 de septiembre del 2007 del sitio ofrecer métricas que permitan a éste tomar de- web del Workshop on Web Engenniering. Santa cisiones que mejoren dicho proceso. Cruz, USA: http://www.ht04.org/workshops/ El entorno de programación propuesto WebEngineering/. debe ser multiplataforma (ejecutarse en sistemas Lussier, S. (2004). New tricks: How open source changed operativos basados en la filosofía de software libre the way my team works. [Versión Electrónica]. o propietarios), razón por lo cual se propone ser IEEE Software, Vol: 21:Pages: 68 - 72. desarrollado utilizando el lenguaje de programa- McDowell, C., Werner, L., Bullock, H. E., y Fernald, ción JAVA, que permite mediante la utilización de J. (2003). The impact of pair programming on máquinas virtuales, ejecutar aplicaciones en múl- student performance, perception and persistence. tiples plataformas. De igual forma, el desarrollo e Recuperado el 18 de septiembre de 2007 del sitio implementación de servicios web (necesarios para web de la IEEE Computer Society. Washington, establecer la comunicación entre los distintos tipos DC, USA: http://csdl.computer.org/dl/ de procesos que conforman el entorno) en JAVA, proceedings/icse/2003/1877/00/18770602. presenta poca o nula complejidad. pdf. 22
  13. 13. Enl@ce: Revista Venezolana de Información, Tecnología y Conocimiento Año 5: No. 3, Septiembre-Diciembre 2008, pp. 11-23 Nawrocki, J. y Wojciechowski, A. (2001). Experimental Williams, L. (2000). The Collaborative Software Pro- evaluation of pair programming. Recuperado el cess. Recuperado el 5 de septiembre de 2007 6 de septiembre del sitio web de la Universidad del sitio web del Departamento de Ciencias de de Massachusetts. USA: http://www2.umassd. la Computación. The University of Utah: http:// edu/swpi/xp/pairprogramming/Nawrocki.pdf www.cs.utah.edu/~lwilliam/. Nosek, J. T. (1998). The case for collaborative progra- Williams, L., Kessler, R. R., Cunningham, W., y Jefries, mming. Commun. [Versión Electrónica] ACM, R. (2000). Strengthening the case for pair pro- 41(3):105-108. gramming. [Versión Electrónica]. IEEE Softw., 17(4):19-25. Pérez-Quiñones, M. A. (1998). Teaching history of pro- gramming languages to undergraduate stu- dents. Recuperado el 18 de septiembre de 2007 del sitio web de la IEEE Computer Society. Was- hington, DC, USA: http://csdl.computer.org/dl/ proceedings/fie/1998/4762/01/00736853.pdf. 23

×