Carlos Rincon, Afredo Acurero...

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

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

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


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


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


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


• 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


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


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


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 programas 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


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


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


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

Carlos Rincon, Afredo Acurero...

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (19)

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie Carlos Rincon, Afredo Acurero...

Ähnlich wie Carlos Rincon, Afredo Acurero... (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (10)

Carlos Rincon, Afredo Acurero...