1. Determinantes de la participación del usuario en proyectos de software
(Determinants of User Involvement in Software Projects)
Rahul Thakurta
Rahul Roy
RESUMEN
El documento presenta resultados de una investigación empírica de los factores que influencian la
participación de los usuarios durante el desarrollo de un proyecto software. La primera parte del estudio utiliza
entrevistas grupales para entender el proceso de participación del usuario en un proyecto de software. Esto culmina
con un “modelo facilitador de participación del usuario” que combina antecedentes relacionados en un modelo de
ecuación estructural para explicar el proceso. En la segunda parte, se valida el modelo en base a encuestas tipo
cuestionario. El análisis de las respuestas identifican dos grupos de factores, es decir, “importancia percibida del
proyecto”, y “percibió la facilidad de la participación del usuario” para ser los conductores primarios detrás de la
“intención del usuario hacia la participación” que lleva a involucrarse. También se describen otros antecedentes
significativos que influencian el proceso. En el resultado de este estudio se espera encontrar una guía de
participación del usuario a nivel de reducción del riesgo del proyecto.
1. INTRODUCCIÓN
La participación de los usuarios en sistemas de desarrollo ha sido un importante tópico de investigación de
sistemas de información en los últimos 50 años. Aún cuando es extensamente aceptado que es un hecho que la
participación de los usuarios es un pre­requisito para obtener el éxito de un proyecto, queda mucho por conocer
acerca de cuándo, cómo, y por qué la participación de los usuarios funciona. En orden a efectivamente facilitar el
proceso, Project managers necesitan apuntar a características específicas del proceso de desarrollo de software que
probablemente influyan la participación de los usuarios durante las etapas de desarrollo del proyecto. Este estudio
presenta un modelo integrado cuidadosamente combinando los distintos factores de influencia positivos y negativos
de la participación de los usuarios. Con esto se espera proveer un mejor entendimiento del fenómeno sobre
diferentes ajustes del proyecto. Este paper examina ciertas características técnicas y de comportamiento, e
investiga su contribución como facilitador de participación de los usuarios.
El paper está organizado como sigue. La sección 2 discute sobre la literatura relevante culminando en el
modelo de investigación que proponemos en el paper. La metodología de la investigación es elaborada en la sección
3, donde primero resumimos la fase 1 de nuestra investigación que comprende en enfocar en entrevistas de grupos,
después describimos nuestro modelo de investigación, y finalmente detallamos la fase 2 (encuesta) en términos de
construcciones del propósito, de la muestra y del estudio. La sección 4 presenta la técnica de análisis de datos
adoptada en este estudio. Los resultados son presentados en la sección 5 y también discutidos. Finalmente, la
sección 6 resume los hallazgos del estudio, abordando las limitaciones, y presentando las futuras oportunidades de
investigación.
2. LITERATURA DE ENCUESTAS
Investigaciones anteriores han estudiado los diferentes aspectos de la participación del usuario en los
proyectos de software. Estos incluyen tanto el proceso (cómo los usuarios se involucren en un
proceso de desarrollo) como los factores de determinación que permiten o inhibir la participación de los usuarios.
Ives & Olson [3] identificaron dos clases de variables condicionales que afectan a la conveniencia de la implicación
del usuario en cualquier situación. Estas eran conocidos como "funciones de participación" (quienes participan y en
qué roles), y "características de desarrollo" (característica del proceso de desarrollo y la etapa del proceso de
desarrollo). En la participación se observó más a cierta clase de usuarios, conocidos como los usuarios principales
(es decir, quienes utilizan directamente el sistema). Ellos observaron en los proyectos estudiados, la participación
era más alta en esos donde la aceptación de usuario era crítica, o donde la información requerida para desarrollar el
proyecto se podría obtener solamente de usuarios. La participación también fue significativamente mayor durante las
etapas de diseño e implementación de la proyecto.
Barki y Hartwick [4] trataron de entender el proceso de participación de los usuarios en un proyecto. Podrían
identificar dos etapas en las que esto sucede. En una primera etapa, el compromiso es a nivel superficial. No
obstante, esto conduce a la formación de creencias sobre el sistema en términos de si es bueno, importante, y
personalmente relevante. La formación de creencias modera la intensidad de la participación en la segunda etapa. El
proceso de formación de creencias, según ellos, depende de las características individuales como la edad, la
educación, el nivel de motivación, etc.
Grudin [5] señaló que la identificación de los usuarios apropiados, proporcionar acceso a los usuarios,
motivar a los evaluadores a implicar a los usuarios, motivar a los usuarios para conseguir que participen en el
1

2. proyecto, son algunos de los factores que aumentan el nivel de participación de usuario.
Wilson y otros [6] por una parte identificó que la presencia de demasiados grupos de usuarios, la carencia de
disponibilidad del tiempo de los usuarios, el que los usuarios carezcan de confianza y motivación para hablar con los
diseñadores, y los usuarios que desconocen los requerimientos, restricciones y tareas de la aplicación, son algunas
de las barreras a la participación del usuario.
Gefen & Ridings [7] observaron deficiencias en las normas de la organización como creadores de obstáculos
en la participación del usuario en proyectos de desarrollo.
A partir de los resultados de estos estudios se desprende que la participación del usuario en proyectos de
software es similar a la aceptación de una nueva tecnología, donde la aceptación depende de lo siguiente:
○ Los usuarios viendo un verdadero valor en el proyecto.
○ Atributos de comportamiento de los usuarios (características demográficas, la motivación intrínseca
y la confianza).
○ Las condiciones favorables (disponibilidad de tiempo, tipo de proyecto, las etapas del proyecto, la
criticidad del proyecto, si el entorno del proyecto facilita la participación).
En términos del proceso, parece ser que el usuario evoluciona a través de la participación de múltiples
etapas, en las que cada etapa un usuario refuerza sus creencias acerca de la condiciones favorables y que decide
su nivel de participación en la siguiente etapa. El nivel inicial de participación, por lo tanto, puede llevar a aumentar
gradualmente el nivel de participación, o puede dar lugar a la retirada gradual, dependiendo de la intención individual
y condiciones favorables.
3. METODOLOGIA DE INVESTIGACION
La investigación descrita en este paper prosiguió en dos fases como se describe abajo. La fase 1 utilizó
entrevistas grupales enfocadas en orden a llegar al modelo facilitador de participación de los usuarios mostrado en la
figura 1. El modelo fue subsecuentemente validado basado en los datos recolectados a través de un instrumento de
encuesta basada en la Web en la fase 2 de nuestra investigación.
3.1. Descripción de la primera parte: Grupo principal
Durante agosto y septiembre de 2008, se llevaron a cabo entrevistas de grupos principal con los directores
de proyectos de cuatro organizaciones de software a fin de reunir la nociones preferidas con respecto a las varias
facetas de la participación de los usuarios durante las etapas de desarrollo de software. La entrevista al grupo
principal fue preferida por sobre entrevista individual tradicional pues el propósito de esta fase de investigación era
llegar un consenso general entre los participantes con respecto a las diferentes facetas de la participación de los
usuarios. Las entrevistas al grupo principal proporcionaron una plataforma correcta para satisfacer estos objetivos y
en el proceso se desarrolló una hipótesis comprobable para la validación subsecuente.
Cuatro rondas de entrevistas a grupos principales fueron llevadas a cabo en organizaciones separadas, y un
total de 14 personas (dos grupos, cada uno compuesto por cuatro miembros, y los otros dos grupos, cada uno
compuesto por tres miembros) participaron en ella. Las entrevistas a grupos principales se llevaron a cabo en las
instalaciones de la oficina del sujeto y fueron registrados para la transcripción y posterior análisis. Las entrevistas
duraron entre una y una hora y media. El método comparativo constante [11] fue utilizado para el análisis del
contenido de la entrevista. El análisis da como resultado, además de que conduce al Modelo Facilitador de
Participación de Usuario propuesto (descrito más adelante), también proporciona interpretación contextual del modelo
construido como sigue:
○ La intención del usuario hacia la participación fue considerada como un indicador de lo difícil que los
usuarios están dispuestos a tratar y de la cantidad de esfuerzo que estos están dispuestos a
ejercer, para participar en el proceso de desarrollo de software.
○ La participación de los usuarios se entiende a partir de las siguientes cuatro dimensiones: la calidad
de la interacción (es decir, la calidad de entradas que el usuario está proporcionando al equipo del
proyecto), la naturaleza de la interacción (es decir, si la interacción de los usuarios con el equipo del
proyecto es espontánea), el nivel de compromiso (es decir, el compromiso mostrado por los
representantes de los usuarios hacia el grupo de proyecto), y la postura psicológica (es decir, el
estado psicológico subjetivo de los usuarios relacionados con todas las decisiones y acciones
tomadas con respecto al proyecto).
○ La importancia percibida del proyecto se define como el grado en que el proyecto está cumpliendo
con el plan estratégico y los requerimientos o necesidades de sus grupos de interés. Se evaluó
principalmente las dimensiones de relevancia (es decir, la relevancia del producto o servicio
prestado por el proyecto de desarrollo de software a sus usuarios finales), y la percepción de pérdida
(es decir, el grado de pérdida posible, por ejemplo, los ingresos monetarios o no monetarios, pérdida
de reputación, imagen de marca, que son probables en caso de que el proyecto fracasa en sus
objetivos).
2

3. ○ La facilidad percibida de la participación del usuario fue interpretada como el grado en el cual los
usuarios sienten que el ambiente del proyecto facilitaría su participación en el proyecto.
○ El interés de los usuarios se interpretó como el afán o la resistencia mostrada por los usuarios hacia
la puesta en práctica del proyecto, y el grado de satisfacción mostrado por los usuarios cuando
tienen la oportunidad de participar del proyecto.
○ La claridad del proceso se identificó como el grado en que los procesos desarrollados durante el
desarrollo del software son transparentes para los usuarios. Los factores positivos a la claridad del
proceso fueron identificados como el conocimiento de los hitos del proyecto y los entregables, la
transparencia de los procesos del proyecto referentes a los usuarios, y la claridad de las métricas
del proyecto.
○ La accesibilidad de los usuarios al proyecto se definió como el grado en que los representantes de
los usuarios eran accesibles con respecto a las diferentes funcionalidades del proyecto que
requerían la intervención del usuario. Los indicadores sugestivos de accesibilidad de los usuarios
fueron identificados como retraso medio (es decir, el tiempo que transcurre entre la solicitud enviada
a los representantes de los usuarios con respecto a determinada tarea, y el cumplimiento de la
misma por los representantes de los usuarios), la facilidad de acceso (es decir, la medida en que a
los usuarios se consideran accesibles desde la organización del proyecto), y la provisión de
necesidad con cita previa (es decir, el grado al el cual las solicitud de citas enviadas por miembros
del proyecto fueron atendidas por los representantes de los usuarios).
○ La percepción de los beneficios del proyecto fue interpretada como los beneficios (ya sean
monetarios o no monetarios), que el proyecto puede aportar a la organización, los usuarios y otras
partes interesadas, y el medio ambiente (es decir, sociedad, gobierno, público, etc).
○ La visibilidad del resultado se define como el grado en que el resultado esperado del proyecto puede
comprobarse con certeza. Las medidas sugestivas de visibilidad de los resultados estaban en
términos de la medida en que la fecha prevista de finalización del proyecto se podía determinar con
certeza, y la cantidad de entregas de proyectos realizados para la organización de usuarios.
○ El término "incertidumbre del proyecto" fue interpretado en términos de riesgos (imprevistos) que
enfrenta un proyecto de software.
○ El término "complejidad del proyecto" fue considerado como un indicador del nivel de complejidad
asociado a un proyecto. Esto fue visto desde dos perspectivas a saber: de gestión (es decir, que
comprende todos los negocios y los aspectos organizativos del proyecto como la dotación de
personal y gestión de proyecto, etc) y técnica (es decir, que comprende todos los aspectos técnicos
del proyecto tales como el número de tecnologías involucradas, etc).
Modelo facilitador de participación del usuario.
Incorporamos las conclusiones pertinentes de la investigación previa en un modelo completo de
construcciones y relaciones para explicar la participación del usuario en proyectos de software. Específicamente nos
enfocamos en “el modelo de aceptación de tecnología (TAM)” desarrollado por F.D. Davis [8]. El TAM intenta proveer
explicaciones de los determinantes de la aceptación de la tecnología que es general, capaz de explicar el
comportamiento del usuario en un amplio rango de las tecnologías de computación del usuario final y las poblaciones
de usuarios, mientras que al mismo tiempo son parsimoniosas y teóricamente justificadas [8]. El TAM postula que
“la utilidad percibida” y “la facilidad de uso percibida” determina “la intención de comportamiento a usar” para usar un
sistema, con “la intención de comportamiento a usar” sirviendo como un mediador de “el uso actual del sistema”. “la
utilidad percibida” es definida como “la probabilidad subjetiva que usando un sistema de aplicación su performance
de trabajo dentro de un contexto organizacional específico” de los usuarios [8]. “La facilidad de uso percibida” se
refiere a “el grado en el cual el usuario espera que el sistema destino sea libre de esfuerzo” [8].
El TAM también sugiere que “la facilidad de uso percibida” afecta positivamente a “la utilidad percibida” lo
que implica que si un sistema es fácil para operar, entonces será percibido como más útil comparado con otros aun
cuando “objetivamente” no lo sean.
Basado en los estudios emergentes, el TAM evolucionado dentro del TAM2 [9], que combinaba los
determinantes generales de la utilidad percibida. Esto subsecuentemente llevó al TAM3 [10], el cual extendía el
TAM2 combinando los determinantes de la facilidad de uso percibida. El objetivo del TAM3 fue servir como un marco
nomológico para alcanzar intervenciones de gestión de la adopción del empleado y el uso de IT.
Dibujando un paralelismo con TAM3 (elaborado después en la sección “la medición de constructores”),
proponemos “el modelo facilitador de participación del usuario” (Figura 1) en el cual creemos modela los
antecedentes la participación del usuario en un proyecto de software. Las relaciones causales mostradas por las
flechas (Figura 1) describe nuestra hipótesis acerca de cómo diferentes constructores (mostrados dentro de óvalos)
influencian la participación del usuario. Las evidencias a favor de los diferentes vínculos fueron derivados basándose
en análisis de cuatro entrevistas de grupos focales discutidas arriba. Las 11 hipótesis implicadas por el diagrama del
modelo son parafraseadas abajo:
● H1: Intención del usuario hacia la participación (UIP) causa la participación del usuario (UI).
3

4. ● H2: Importancia del proyecto percibida (PPI) causa la intención del usuario hacia la participación (UIP).
● H3: Facilidad de participación del usuario percibida (PEUP) causa intención del usuario hacia la participación
(UIP).
● H4: Interés del usuario (UsI) causa causa intención del usuario hacia la participación (UIP).
● H5: Interés del usuario (UsI) causa facilidad de participación del usuario percibida (PEUP).
● H6: Claridad del proceso (PC) causa facilidad de participación del usuario percibida (PEUP).
● H7: Accesibilidad del usuario al proyecto (UAP) causa facilidad de participación del usuario percibida
(PEUP).
● H8: Beneficios del proyecto percibidos (PPB) causa importancia del proyecto percibida (PPI).
● H9: Visibilidad de los resultados (OV) causa importancia del proyecto percibida (PPI).
● H10: Incertidumbre del proyecto (PU) causa visibilidad de los resultados (OV).
● H11: Complejidad del proyecto (PC) causa visibilidad de los resultados (OV).
Figura 1. Modelo facilitador de participación del usuario
3.2. Encuestas
Un instrumento de encuesta basada en la web contra las pautas de Straubs fue utilizado en la fase 2 en
orden a validar el Modelo facilitador de participación del usuario propuesto. Pre­testing se llevó a cabo en orden a
mejorar la confiabilidad del cuestionario de la encuesta y evaluar la validez del contenido (es decir, el grado en el
cual una medida representa todas las facetas de una construcción dada). El cuestionario final contenía cuatro
secciones. La primera sección (introducción) contenía información del propósito de la investigación. La segunda
sección solicitaba detalles demográficos de los encuestados. La tercera sección solicitaba detalles específicos del
proyecto y también contenía preguntas relacionadas a la experiencia y percepción de los encuestados acerca de
participación en proyectos de software agrupadas de acuerdo a once constructores identificados que el modelo
retrata. Las preguntas sobre precisión de las respuestas y comentarios fueron colocadas en la sección final.
3.2.1. Fase 2 ­ Selección de la muestra
La encuesta fue destinada individuos que habían participado como usuarios (usuarios del negocio, usuarios
académicos, cliente del proyecto o equivalente) en un proyecto de desarrollo de software. La participación pudo
haber sido dando entradas y sugerencias al equipo de desarrollo de software, chequeando el estado del proyecto, o
por curiosidad general. Una combinación de muestro por conveniencia y una cadena de estrategia de muestreo fue
adoptada como grupo de investigación enfrentando problemas accediendo a la muestra de estudio. Las invitaciones
fueron enviadas a los profesionales de software con solicitud de reenvío a sus grupos de usuarios del proyecto, y a
probables candidatos ajustando los criterios de muestreo con solicitud de reenvío a sus conocidos. Un contador de
acceso a la página de la encuesta contó un total de 373 individuos para ver la encuesta, fuera de los cuales 78
finalmente finalizaron la encuesta (una tasa de respuesta del 20.9%). La baja tasa de respuesta explica la dificultad
4

5. encontrada en el proceso de contactar la población base ya que muchos eran reacios a compartir sus experiencias
sobre los proyectos, citando que la información era confidencial.
De la muestra final (78), 40% de los encuestados indicaron tener más de tres o cuatro años de experiencia
respecto al uso previo de aplicaciones similares a la que era provista por el proyecto de software. También el 78%
de los encuestados se encontraron familiarizados en un cierto nivel con el dominio del proyecto. Todos estos
indicaron que la mayoría de los usuarios que participaron durante el proceso de desarrollo del software tuvieron algún
nivel de competencia en la aplicación siendo desarrollada. El impacto de los prejuicios locales (como cualquier
evento particular influenciando acciones subsecuentes) sobre la respuesta de la encuesta fue probablemente bajo en
este caso. Finalmente, una mayoría (56%) de los encuestados fueron usuarios internos implicando una categoría
MIS de aplicaciones fueron desarrollados para uso interno dentro de la organización, con los usuarios perteneciendo
a diferentes departamentos de la organización del software ejecutando el proyecto.
3.2.2. Medición de los constructores
Las once construcciones estructurales demostradas en el modelo (figura 1) fueron medidas en este estudio
como descrito más abajo. En cada caso hemos querido evaluar las creencias de los participantes acerca de si las
construcciones de medición reflejan ciertamente la construcción estructural.
Implicación del usuario: Esta construcción corresponde a la construcción “uso del sistema actual” de TAM3 [10]. En
este estudio, explicamos determinantes de la participación de los usuario como en TAM3, que explica
comportamiento del uso de sistema. Las investigaciones anteriores han medido la participación del usuario como
construcciones de un solo elemento o de varios elementos sobre la base de escalas tipo Likert [15]. Durante la fase
1 de nuestro estudio, los participantes han mencionado cuatro perspectivas diferentes de calidad, es decir, la
interacción de participación de los usuarios, la naturaleza de la interacción, el nivel de compromiso, y la postura
psicológica. En consecuencia, se deriva un constructor compuesto de 4 elementos para medir la participación del
usuario como se describe a continuación:
○ Calidad de la interacción: Si la calidad de los insumos proporcionados a la organización del proyecto
es una indicación de la participación de los usuarios.
○ Interacción Natural: Si la función de usuario y su responsabilidad asignada con respecto a las tareas
del proyecto son las promotoras de la participación del usuario en el proyecto.
○ Nivel de compromiso: Si el nivel de compromiso de los usuarios es un indicador de participación de
los usuarios cada vez mayor.
○ Actitud psicológica: aumento de la importancia y relevancia del proyecto para los usuarios es una
indicación de la participación de los usuarios cada vez mayor.
El nivel de acuerdo de los encuestados para cada uno de estos cuatro ítems osciló entre (1) "Totalmente en
desacuerdo" a (5) "Totalmente de acuerdo" (escala Likert).
La intención del usuario hacia la participación: La intención en el comportamiento de los usuarios para que participen
en el proyecto de desarrollo de software se mide por esta construcción. Los elementos de medición para la conducta
de intención ha sido adoptada de Davis [8], y luego modificado para que coincida con el contexto de estudio. La
construcción compuesta de 3 elementos, a continuación, fue concebida para medir la intención de los usuarios:
○ Plan de comunicación: La medida del plan del usuario para comunicarse con el equipo de desarrollo
de software
○ Intención de Representación: El deseo de ser uno de los principales usuarios de los proyectos de
desarrollo de software
○ Intención General de Participaciones: intención general del usuario para participar en un proyecto de
desarrollo de software
El nivel de acuerdo demandado a estos artículos se ha medido en la escala de 5 puntos que oscilan entre
"Totalmente en desacuerdo" y "Totalmente de acuerdo", como se indicó anteriormente.
La percepción de facilidad de participación del usuario: Los elementos de facilidad percibida también fue adaptado a
partir de investigaciones previas [8], y se han hecho modificaciones para que reflejara nuestro contexto de estudio.
Los elementos de medición para este se dan a continuación:
○ Facilidad de Selección: Si la selección fácil como participante en el proyecto de desarrollo de
software es un indicador
○ Facilidad de participación: Si una interacción fluida y bien definida de usuarios con la organización
de desarrollo de software es un indicador
A los encuestados se les pidió que indicaran el grado de acuerdo o desacuerdo con los cinco puntos de la
escala de Likert como se mencionó anteriormente.
5

6. Interés de los usuarios: El interés de los usuarios es paralelo a “la construcción percibida del disfrute” (es decir el
grado a el cual la actividad de usar un sistema específico se percibe para ser agradable por derecho propio) de
TAM3 ya que ambas construcciones implican un sentido de entusiasmo al ejecutar la actividad. La medida del
interés de los usuarios se deriva de la fase 1 y resulta de la siguiente manera:
○ Afán de participación: Si el encuestado estaba ansioso por participar en el proyecto de desarrollo de
software
○ Placer de participar: Si el encuestado tuvo placer de participar en el proyecto de desarrollo de
software
○ Interés General: Si el nivel de interés general, contribuye al interés de los usuarios en participar en
proyectos de software
Cada uno de estos tres elementos se midió con la escala que se mencionó anteriormente.
Claridad de proceso: Esta construcción se asemeja a la "utilidad objetiva" de TAM3. Usabilidad objetiva proporciona
una medida del grado de exigencia de esfuerzo real para llevar a cabo una tarea [10]. La evaluación del esfuerzo real
está relacionada con "la claridad del proceso", que permitirá una mejor evaluación de la situación. Con base en los
resultados de la fase 1, una construcción de 3 elementos fue ideada para medir la claridad del proceso, que capturó
la conciencia de los hitos del proyecto ("La conciencia Milestone"), la comprensibilidad de las métricas del proyecto
de los usuarios participantes (métrica “bien definida") , y una medida compuesta ("Procesos transparentes"). Las
opciones de respuesta osciló entre (1) "Totalmente en desacuerdo" y (5) "Totalmente de acuerdo".
Accesibilidad del usuario al proyecto: Esta construcción se asemeja a la "Percepción de Control Externo" de TAM3.
Ambos proporcionan una indicación del grado en que los recursos están disponibles cuando se necesitan en la
realización de una actividad. Sobre la base de la fase 1, la accesibilidad del usuario fue medida en términos de
retardo medio, facilidad del acercamiento, facilidad de acercamiento, y la prestación de necesidad, con cita previa.
De ellos, la demora se mide en una escala de 5 puntos entre (1) "Muy Alto" a (5) "Muy Bajo". Para el segundo y
tercer elemento, se les pidió a los encuestados que indicaran su nivel de acuerdo / desacuerdo sobre la escala
Likert.
Percepción de la importancia del proyecto: Esto corresponde al constructor de "utilidad percibida" de TAM3. Similar
a esta última, la “percepción de la importancia del proyecto" ofrece un razonamiento detrás del beneficio de
comprometerse con una actividad (en este caso, los beneficios asociados con la participación en el proyecto). Esto
se evaluó en términos de relevancia y sobre la base de la percepción de pérdidas de los resultados de la fase 1.
Cada uno de estos dos temas fue evaluados en la escala de 5 puntos de acuerdo / desacuerdo como se explicó
anteriormente.
La percepción de beneficios del proyecto: Esta construcción se asemeja a la "Calidad de salida" (es decir una
medida del grado a el cual un individuo cree que el sistema realiza sus tareas del trabajo bien) de la construcción de
TAM3. El grado del aumento de la “calidad de la salida” en lo referente a una cierta actividad se podría considerar
como indicador de las ventajas probables que se asocian a la terminación correcta de esa actividad. Teniendo en
cuenta los aspectos monetarios y no monetarios de los beneficios del proyecto, fue construida una medida de 2
elementos que consta de "utilidad general" y "reducción de Costos". Esto ayudaría a evaluar las creencias de los
usuarios acerca de si el producto / servicio prestado por el proyecto de software sería útil a sus usuarios, y asistirá a
la reducción de costes.
Visibilidad del resultado: Esta construcción es análoga a la "demostrabilidad del resultado" (es decir, el grado en que
un individuo cree que los resultados de la utilización de un sistema son tangibles, observables y comunicables) de la
construcción de TAM3.La “demostrabilidad del resultado” proporciona la evalucación de los resultados que se facilita
con visibilidad creciente del resultado. La medida de la visibilidad del resultado esta constituida por los siguientes
elementos:
○ Visibilidad del progreso: Grado en que la presencia de las prestaciones de las entregas ayudaron en
la estimación de la fecha de finalización definitiva del proyecto.
○ Funcionalidad del proyecto: Grado en que la presencia de las prestaciones de las entregas ayudaron
en la comprensión de la funcionalidad del producto del trabajo.
Estos dos elementos identificados en base a la fase 1 de análisis se consideraron en la escala de 5 puntos
de acuerdo / desacuerdo como se explicó anteriormente.
Incertidumbre del proyecto: Esto se puede considerar como el antecedente de la construcción de "demostrabilidad
del resultado" de TAM3. Obviamente, en presencia de una mayor incertidumbre de"demostrabilidad del resultado" es
6

7. probable que sea menor. Las entrevistas con grupos principales sugieren la identificación de la incertidumbre del
proyecto en términos de los riesgos asociados con el proyecto. Keil [16] ha propuesto medir el nivel de incertidumbre
en las cuatro dimensiones que la comprenden:
○ La incertidumbre las partes interesadas: la incertidumbre que rige a los usuarios y otros interesados
​
en el proyecto (relacionado con el apoyo de la dirección, la cooperación del usuario, el compromiso,
la actitud hacia el cambio, los conflictos, etc).
○ Ámbito de incertidumbre: La incertidumbre asociada con la incapacidad de director del proyecto de
la empresa de desarrollo de software para juzgar el alcance del proyecto (que incluye también los
riesgos asociados con las funcionalidades requeridas proyecto).
○ Incertidumbre de la ejecución: La incertidumbre asociada con la ejecución del proyecto (relacionado
con la dotación de personal inadecuado al proyecto, metodología de desarrollo inadecuada, falta de
definición de roles y responsabilidades, y planificación deficiente de los proyectos y control, etc).
○ Incertidumbre ambiental: La incertidumbre asociada con el entorno del proyecto (como cambios en
el entorno de la organización, las dependencias externas, políticas de la empresa, etc).
La escala de medición de este elementos esta compueta por la medida de cada una de estas cuatro
dimensiones. Pidieron a los respondedores indicar el nivel de incertidumbre asociado a cada dimensión entre (1)
“Muy bajo”, y (5) “Muy arriba” según lo experimentado en los proyectos referidos.
Complejidad del proyecto: Al igual que "la incertidumbre del proyecto", esta construcción también se puede visualizar
como antecedente a la "demostrabilidad del resultado". El aumento en la complejidad es probable que influya
negativamente en la percepción de la medida en que el resultado podría ser comprensible para su destinatario. Las
dos dimensiones de la complejidad del proyecto que surgieron de la fase 1 de análisis fueron la “complejidad técnica”
y la “complejidad de gestión”. Cada una se midió utilizando un único elemento. Las opciones de respuesta estaban
establecidas en una escala de 5 puntos que oscila entre (1) "Muy bajo", y (5) "Muy Alto".
4.ANÁLISIS DE DATOS
El análisis consistió en primer lugar en una evaluación del modelo de medición y paralelamente una
evaluación del modelo estructural. Cabe recordar que los constructores en el modelo estructural no son directamente
observables y tiene que ser evaluados en términos de medición asociada a la construcción (por ejemplo, la
participación de los usuarios medidos por la calidad de la participación, la naturaleza de la interacción, el nivel de
compromiso, la actitud psicológica). El modelo de ecuaciones estructurales se refiere a las relaciones entre la
medición de constructores como así también al modelo de medición. La evaluación del modelo consiste en lo
siguiente:
○ La evaluación de las cargas de elementos individuales (es decir, la fuerza de la asociación entre un
elemento y el constructor correspondiente al que se refería).
○ La estimación de los coeficientes de consistencia interna (medida de fiabilidad) para cada bloque de
indicadores (una bloque se refiere a un conjunto de elementos que están asociados con una
construcción particular que estos elementos miden).
○ La evaluación de la validez de constructor: la medida en que la puesta en marcha de una
construcción de realidad mide lo que pretende medir. Esto se logra a través de la evaluación de la
validez de contenido (definido anteriormente), la validez convergente (es decir, el grado en que las
medidas que deben ser relacionadas en validez de la realidad relacionada), y el discriminante (es
decir, el grado en que los elementos se diferencian entre constructores o miden conceptos distintos)
○ La estimación de coeficientes de trayectoria: Esto proporciona una estimación de la fuerza y ​ ​
la
señal de la las relaciones entre las diferentes constructores.
Utilizamos mínimos cuadrados parciales (PLS), una técnica multivariante que facilita que facilita la prueba
de las propiedades psicométricas de las escalas utilizadas para medir un constructor. Estima simultáneamente los
parámetros del modelo estructural. Es decir, la magnitud y dirección de las relaciones entre el los constructores del
modelo [17]. La siguientes características de PLS lo hizo adecuado dado
el propósito del estudio [18]:
○ La técnica es particularmente aplicable en la investigación exploratoria donde las relaciones pueden
existir entre los constructores.
○ La técnica es conocida para funcionar bien incluso para un muestra de tamaño relativamente
pequeño.
○ La técnica no requiere puntos de referencia para ser una distribución normal.
La evaluación del modelo se realizó con muestra del total general. El software de SMARTPLS 2.0 fue
utilizado para este análisis. Los coeficientes de trayectoria estimados del modelo se calcularon utilizando la
7

8. secuencia de arranque técnica [18]. Los resultados se discuten a continuación.
5. RESULTADOS
5.1. Evaluación del modelo de medición
La evaluación de la carga de los elementos individuales indicaron si los elementos de medición cargaron
suficiente en las construcciones correspondientes. Las cargas de cada uno de los elementos de medición se
muestran en la Figura 2. Cada óvalo en el gráfico representa una construcción. Los rectángulos asociados con una
construcción muestran los elementos de medición que le corresponden y su medida correspondiente de carga. En
las cargas de los 30 puntos de medición que se muestran en la Figura 2 se encontró que más de 0,50 fueron
significativos sobre la base de las directrices establecidas en Hair [19].
En el siguiente nivel de validación se evaluó la fiabilidad y la validez del modelo. La consistencia interna del
modelo de medición se evaluó mediante el cálculo de la fiabilidad compuesta (CR). Excepto la incertidumbre del
proyecto (PU), el valor de CR para todas las otras construcciones estaban por encima del valor mínimo de 0,70 (no
mostrado) [19]. El Cronbach alfa de las construcciones se encontró también en un rango aceptable, es decir, por
encima de 0,50 (no mostrado) [20].
La validez convergente se evaluó sobre la base de la varianza promedio extraída (AVE). Aquí también,
excepto la incertidumbre del proyecto (PU), todas las otras construcciones cumplen la directriz de mayor que 0,50
AVE (no mostrado) [19], y por lo tanto se considera satisfactoria. La medida de validez discriminante también se
encontró satisfactoria para todas las construcciones (no mostradas).
La construcción de la incertidumbre del proyecto no cumplía las directrices de requisitos mínimos de CR y el
AVE. Sin embargo se ha conservado la construcción, ya que se deriva de evidencias de literaturas [16], y su
coeficiente alfa de Cronbach fue satisfactorio (0.796).
5.2. El modelo estructurado
El modelo estructurado se compone de las construcciones y las relaciones entre ellos. Este fue evaluado
con respecto a la significación estadística de los coeficientes de trayectoria estimados. Las relaciones significativas
que surgieron del estudio se muestran con "**" en la figura 2. Los resultados proporcionaron evidencias a favor de
las hipótesis principales: H1, H2, H3, H5, H8, y H11.
Figura 2. Evaluación del Modelo facilitador de participación de usuarios
Contrariamente a nuestra hipótesis, la relación entre la incertidumbre del proyecto y la visibilidad de
8

9. resultados (H10) surgió como negativa. Esto puede explicarse considerando que la percepción de la incertidumbre
del proyecto (visto como riesgo) por la organización del usuario y la organización del proyecto pueden ser diferente.
Los elementos de medición de la incertidumbre del proyecto se hicieron en base a cómo fueron percibidos los
riesgos de la en la organización del proyecto. Sin embargo, nuestro estudio se centró en los usuarios del proyecto.
Esto sugiere la necesidad de perfeccionar la construcción con el fin de captar la perspectiva deseada.
La contribución de la visibilidad del resultado a la importancia percibida del proyecto fue positiva pero no
estadísticamente significativa (H9). La visibilidad del resultado fue determinada en nuestro modelo en términos de
visibilidad de los productos a entregar del proyecto y de los plazos de proyecto. El resultado no mide la importancia
de estos dos atributos que indican el estado del proyecto, sino que destaca que este factor no puede ser un factor
determinante a la hora de evaluar la importancia del proyecto. El rechazo de la hipótesis (H6) señala de manera
similar a un conjunto diferente de los determinantes de la facilidad de involucrarse en el proyecto de lo que ha sido
capturada usando la construcción de proceso de la claridad en nuestro estudio.
La accesibilidad del usuario al proyecto no contribuyó como un determinante significativo en la facilidad
percibida de la participación del usuario (H7). Esto podría ser debido a que una alta proporción de los encuestados
eran usuarios internos del proyecto (es decir, departamentos internos que actúan como los usuarios del proyecto,
como el departamento de finanzas, departamento de recursos humanos, etc) y no previeron la accesibilidad como un
obstáculo para la participación en el proyecto de software.
La relación directa entre el interés de los usuarios y la intención del usuario hacia la participación no surgió
como un significante (H4). Sin embargo, la hipótesis H5 (interés de los usuarios → facilidad percibida de la
participación del usuario) fue aceptada. De los usuarios que estaban interesados ​ ​
en participar, se espera que se
comprometan a esta conducta por el simple hecho de hacerlo. Estos usuarios tienden a subestimar la dificultad
asociada con la participación en el proceso porque les gusta lo que hacen. Por esta razón, la relación entre el interés
del usuario y la intención del usuario hacia la participación resultó ser mediada por la facilidad percibida de la
participación del usuario.
6. CONCLUSIÓN
La importancia de la entender los potenciales facilitadores de la participación de los usuarios durante el
desarrollo de software es crítica debido al hecho de que la falta de participación de los usuarios es probable que
resulte en los esfuerzos frustrados. Los resultados de esta investigación identifican ciertas condiciones y
características de comportamiento que permitan e influyen en la participación de los usuarios durante el proyecto.
Los resultados indican la intención hacia la participación como uno de los conductores que influencian la implicación
del usuario. La formación de la intención, a su vez se encuentra afectada por la importancia del proyecto para los
usuarios, y cuánto se percibe del entorno del proyecto lo que favorece a la participación. Estos dos últimas se
encontraron nuevamente para ser impulsada por la percepción de los beneficios del proyecto y el nivel de interés de
los usuarios, respectivamente. Los resultados ayudaron a explicar la transición de la participación de los usuarios
con el tiempo y el proceso, que aborda las limitaciones de estudios anteriores [3, 4] que veían la participación del
usuario como un proceso estático. Integrando los diversos factores en un marco global podemos explicar la variación
(o la carencia de ella) en la implicación del usuario en un cierto plazo bajo diverso ajuste del proyecto.
Este trabajo no está exento de limitaciones. Una baja tasa de respuesta y el tamaño de la muestra se
obtuvieron para este estudio, que podría limitar la fiabilidad de los resultados. Una tasa de respuesta baja y un
tamaño pequeño de muestra fueron tomados, por lo que este estudio puede limitar la confiabilidad de resultados. Se
usaron las propias medidas reportadas, que son vulnerables a sesgos subjetivos. La posibilidad de errores de
medición también pueden determinarse ya que algunas de las construcciones que se obtuvieron fueron derivadas de
la literatura divulgada, que en su mayoría se centró en el lado de la organización del proyecto, y por lo tanto la
interpretación de la organización de los usuarios es probable que sea diferente. Los efectos de la causalidad no se
pueden explorar claramente debido a la naturaleza transversal del estudio. Los resultados también pueden tener un
sesgo del muestreo porque la colección de datos fue restringida en la India solamente. Otras generalizaciones sólo
se pueden hacer con confianza a través de repeticiones y ampliaciones del estudio.
Los resultados tienen implicaciones para la gestión de proyectos. El estudio describe las formas preferidas
de definir y medir algunas de las construcciones capturadas en esta investigación (por ejemplo, la incertidumbre del
proyecto, la claridad del proceso
, el interés del usuario, etc), y por lo tanto, es probable que sea beneficioso para las organizaciones en
términos de identificar oportunidades de mejora. Los antecedentes significativos en la participación del usuario que
surgieron de los resultados son manijas específicas que se pueden utilizar para gestionar el nivel de participación de
los usuarios en los proyectos.
Además de abordar las limitaciones, las investigaciones futuras puede mirar en las relaciones no
significativas que no pudieron ser validadas en nuestro estudio, y en el proceso de derivar las causas subyacentes.
Las variaciones bajas que se explican en nuestro estudio indican la presencia de otros factores que influyen en los
fenómenos estudiados, lo que también se pueden explorar en proyectos futuros.
9

10. 7. REFERENCIAS
[1] S. Kujala, "Effective user involvement in product development by improving the analysis of user needs", Behaviour and
Information Technology, 2008.
[2] J. Y. Mao, and M.L. Markus, "A Critical Evaluation of User Participation Research: Gaps and Future Directions",
Proceedings of Pacific Asia Conference on Information Systems, 2004.
[3] B. Ives, and M. H Olson, "User Involvement and MIS Success: A Review of Research", Management Science, 1984.
[4] H. Barki, and J. Hartwick, "User participation and user involvement in information system development", Proceedings of the
24th Annual Hawaii International Conference on System Sciences, 1991.
[5] J. Grudin, "Systematic Sources of Suboptimal Interface Design in Large Product Development Organizations",
Human­Computer Interaction, 1991.
[6] A. Wilson, M. Bekker, P. Johnson, and H. Johnson "Helping and Hindering User Involvement ­ A Tale of Everyday Design",
Proceedings of the Conference on Human Factors in Computing Systems, 1997.
[7] D. Gefen, and C. M. Ridings, "IT Acceptance: Managing User – IT Group Boundaries", The DATA BASE for Advances in
Information Systems, 2003.
[8] F. D. Davis, "Perceived usefulness, perceived ease of use, and user acceptance of information technology", MIS Quarterly,
1989.
[9] V. Venkatesh, and F. D. Davis, "A theoretical extension of the technology acceptance model: Four longitudinal field
studies", Management Science, 2000.
[10] V. Venkatesh, and H. Bala, "Technology Acceptance Model 3 and a Research Agenda on Interventions", Decision
Sciences, 2008.
[11] Glaser, B., and Strauss, A., The Discovery of Grounded Theory: Strategies for Qualitative Research, Aldine Publishing
Co., Chicago, IL, 1967.
[12] Patton, M.Q., Qualitative Research and Evaluation Methods, Sage Publications, Newbury Park, California, 2001.
[13] C. Jones, "Software Sizing", IEEE Review, 1999.
[14] D.W. Straub, "Validating Instruments in MIS Research", MIS Quarterly, 1989.
[15] H. Barki, and J. Hartwick, "Measuring User Participation, User Involvement, and User Attitude", MIS Quarterly, 1994.
[16] M. Keil, P.E. Cule, K. Lyytinen, and R.C. Schmidt, "A Framework for Identifying Software Project Risks", Communications
of the ACM, 1998.
[17] Fornell, C.R., A Second Generation of Multivariate Analysis, Praeger Publishers, New York, 1982.
[18] W.W. Chin, "The Partial Least Squares Approach to Structural Equation Modeling", In Modern Methods for Business
Research, G.A. Marcoulides (ed.), Lawrence Erlbaum Associates, Mahwah, NJ, 1998.
[19] Hair. J.F., Anderson, R.E., Tatham, R.L., and Black, W.C., Multivariate Data Analysis, Pearson Education Inc, Upper
Saddle River, NJ, 2006.
[20] George, D., and Mallery, P., SPSS for Windows step by step: A simple guide and reference, 11.0 update, Allyn and Bacon,
Boston, 2003.
10