Determinantes de la participación del usuario en proyectos de software                            (Determinants of User In...
proyecto, son algunos de los factores que aumentan el nivel de participación de usuario.        Wilson y otros [6] por una...
○   La facilidad percibida de la participación del usuario fue interpretada como el grado en el cual los                us...
●   H2: Importancia del proyecto percibida (PPI) causa la intención del usuario hacia la participación (UIP).    ●   H3: F...
encontrada en el proceso de contactar la población base ya que muchos eran reacios a compartir sus experienciassobre los p...
Interés de los usuarios: El interés de los usuarios es paralelo a “la construcción percibida del disfrute” (es decir elgra...
probable que sea menor. Las entrevistas con grupos principales sugieren la identificación de la incertidumbre delproyecto ...
secuencia de arranque técnica [18]. Los resultados se discuten a continuación.5. RESULTADOS5.1. Evaluación del modelo de m...
resultados (H10) surgió como negativa. Esto puede explicarse considerando que la percepción de la incertidumbredel proyect...
7. REFERENCIAS[1] S. Kujala, "Effective user involvement in product development by improving the analysis of user needs", ...
Determinants of user involvement in software projects
Upcoming SlideShare
Loading in …5
×

Determinants of user involvement in software projects

302 views
211 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

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

No notes for slide

Determinants of user involvement in software projects

  1. 1. Determinantes de la participación del usuario en proyectos de software (Determinants of User Involvement in Software Projects) Rahul Thakurta Rahul RoyRESUMEN El documento presenta resultados de una investigación empírica de los factores que influencian laparticipación de los usuarios durante el desarrollo de un proyecto software. La primera parte del estudio utilizaentrevistas grupales para entender el proceso de participación del usuario en un proyecto de software. Esto culminacon un “modelo facilitador de participación del usuario” que combina antecedentes relacionados en un modelo deecuación estructural para explicar el proceso. En la segunda parte, se valida el modelo en base a encuestas tipocuestionario. El análisis de las respuestas identifican dos grupos de factores, es decir, “importancia percibida delproyecto”, 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 antecedentessignificativos que influencian el proceso. En el resultado de este estudio se espera encontrar una guía departicipació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 desistemas de información en los últimos 50 años. Aún cuando es extensamente aceptado que es un hecho que laparticipación de los usuarios es un pre­requisito para obtener el éxito de un proyecto, queda mucho por conoceracerca de cuándo, cómo, y por qué la participación de los usuarios funciona. En orden a efectivamente facilitar elproceso, Project managers necesitan apuntar a características específicas del proceso de desarrollo de software queprobablemente influyan la participación de los usuarios durante las etapas de desarrollo del proyecto. Este estudiopresenta un modelo integrado cuidadosamente combinando los distintos factores de influencia positivos y negativosde la participación de los usuarios. Con esto se espera proveer un mejor entendimiento del fenómeno sobrediferentes ajustes del proyecto. Este paper examina ciertas características técnicas y de comportamiento, einvestiga 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 elmodelo de investigación que proponemos en el paper. La metodología de la investigación es elaborada en la sección3, 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 deconstrucciones del propósito, de la muestra y del estudio. La sección 4 presenta la técnica de análisis de datosadoptada en este estudio. Los resultados son presentados en la sección 5 y también discutidos. Finalmente, lasección 6 resume los hallazgos del estudio, abordando las limitaciones, y presentando las futuras oportunidades deinvestigación.2. LITERATURA DE ENCUESTAS Investigaciones anteriores han estudiado los diferentes aspectos de la participación del usuario en losproyectos de software. Estos incluyen tanto el proceso (cómo los usuarios se involucren en unproceso 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óndel usuario en cualquier situación. Estas eran conocidos como "funciones de participación" (quienes participan y enqué roles), y "características de desarrollo" (característica del proceso de desarrollo y la etapa del proceso dedesarrollo). 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ónera más alta en esos donde la aceptación de usuario era crítica, o donde la información requerida para desarrollar elproyecto se podría obtener solamente de usuarios. La participación también fue significativamente mayor durante lasetapas 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íanidentificar dos etapas en las que esto sucede. En una primera etapa, el compromiso es a nivel superficial. Noobstante, esto conduce a la formación de creencias sobre el sistema en términos de si es bueno, importante, ypersonalmente relevante. La formación de creencias modera la intensidad de la participación en la segunda etapa. Elproceso de formación de creencias, según ellos, depende de las características individuales como la edad, laeducació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. 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 dedisponibilidad del tiempo de los usuarios, el que los usuarios carezcan de confianza y motivación para hablar con losdiseñadores, y los usuarios que desconocen los requerimientos, restricciones y tareas de la aplicación, son algunasde las barreras a la participación del usuario. Gefen & Ridings [7] observaron deficiencias en las normas de la organización como creadores de obstáculosen 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 desoftware 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últiplesetapas, en las que cada etapa un usuario refuerza sus creencias acerca de la condiciones favorables y que decidesu nivel de participación en la siguiente etapa. El nivel inicial de participación, por lo tanto, puede llevar a aumentargradualmente el nivel de participación, o puede dar lugar a la retirada gradual, dependiendo de la intención individualy 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 lafigura 1. El modelo fue subsecuentemente validado basado en los datos recolectados a través de un instrumento deencuesta 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 directoresde proyectos de cuatro organizaciones de software a fin de reunir la nociones preferidas con respecto a las variasfacetas de la participación de los usuarios durante las etapas de desarrollo de software. La entrevista al grupoprincipal fue preferida por sobre entrevista individual tradicional pues el propósito de esta fase de investigación erallegar un consenso general entre los participantes con respecto a las diferentes facetas de la participación de losusuarios. Las entrevistas al grupo principal proporcionaron una plataforma correcta para satisfacer estos objetivos yen 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 untotal de 14 personas (dos grupos, cada uno compuesto por cuatro miembros, y los otros dos grupos, cada unocompuesto por tres miembros) participaron en ella. Las entrevistas a grupos principales se llevaron a cabo en lasinstalaciones de la oficina del sujeto y fueron registrados para la transcripción y posterior análisis. Las entrevistasduraron entre una y una hora y media. El método comparativo constante [11] fue utilizado para el análisis delcontenido de la entrevista. El análisis da como resultado, además de que conduce al Modelo Facilitador deParticipación de Usuario propuesto (descrito más adelante), también proporciona interpretación contextual del modeloconstruido 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. 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 deconstrucciones y relaciones para explicar la participación del usuario en proyectos de software. Específicamente nosenfocamos en “el modelo de aceptación de tecnología (TAM)” desarrollado por F.D. Davis [8]. El TAM intenta proveerexplicaciones de los determinantes de la aceptación de la tecnología que es general, capaz de explicar elcomportamiento del usuario en un amplio rango de las tecnologías de computación del usuario final y las poblacionesde 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 unsistema, con “la intención de comportamiento a usar” sirviendo como un mediador de “el uso actual del sistema”. “lautilidad percibida” es definida como “la probabilidad subjetiva que usando un sistema de aplicación su performancede trabajo dentro de un contexto organizacional específico” de los usuarios [8]. “La facilidad de uso percibida” serefiere 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” loque implica que si un sistema es fácil para operar, entonces será percibido como más útil comparado con otros auncuando “objetivamente” no lo sean. Basado en los estudios emergentes, el TAM evolucionado dentro del TAM2 [9], que combinaba losdeterminantes generales de la utilidad percibida. Esto subsecuentemente llevó al TAM3 [10], el cual extendía elTAM2 combinando los determinantes de la facilidad de uso percibida. El objetivo del TAM3 fue servir como un marconomoló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 losantecedentes la participación del usuario en un proyecto de software. Las relaciones causales mostradas por lasflechas (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ándoseen análisis de cuatro entrevistas de grupos focales discutidas arriba. Las 11 hipótesis implicadas por el diagrama delmodelo son parafraseadas abajo: ● H1: Intención del usuario hacia la participación (UIP) causa la participación del usuario (UI). 3
  4. 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 usuario3.2. Encuestas Un instrumento de encuesta basada en la web contra las pautas de Straubs fue utilizado en la fase 2 enorden a validar el Modelo facilitador de participación del usuario propuesto. Pre­testing se llevó a cabo en orden amejorar la confiabilidad del cuestionario de la encuesta y evaluar la validez del contenido (es decir, el grado en elcual una medida representa todas las facetas de una construcción dada). El cuestionario final contenía cuatrosecciones. La primera sección (introducción) contenía información del propósito de la investigación. La segundasección solicitaba detalles demográficos de los encuestados. La tercera sección solicitaba detalles específicos delproyecto y también contenía preguntas relacionadas a la experiencia y percepción de los encuestados acerca departicipación en proyectos de software agrupadas de acuerdo a once constructores identificados que el modeloretrata. 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, usuariosacadémicos, cliente del proyecto o equivalente) en un proyecto de desarrollo de software. La participación pudohaber sido dando entradas y sugerencias al equipo de desarrollo de software, chequeando el estado del proyecto, opor curiosidad general. Una combinación de muestro por conveniencia y una cadena de estrategia de muestreo fueadoptada como grupo de investigación enfrentando problemas accediendo a la muestra de estudio. Las invitacionesfueron enviadas a los profesionales de software con solicitud de reenvío a sus grupos de usuarios del proyecto, y aprobables candidatos ajustando los criterios de muestreo con solicitud de reenvío a sus conocidos. Un contador deacceso a la página de la encuesta contó un total de 373 individuos para ver la encuesta, fuera de los cuales 78finalmente finalizaron la encuesta (una tasa de respuesta del 20.9%). La baja tasa de respuesta explica la dificultad 4
  5. 5. encontrada en el proceso de contactar la población base ya que muchos eran reacios a compartir sus experienciassobre 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 experienciarespecto 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 estosindicaron que la mayoría de los usuarios que participaron durante el proceso de desarrollo del software tuvieron algúnnivel de competencia en la aplicación siendo desarrollada. El impacto de los prejuicios locales (como cualquierevento particular influenciando acciones subsecuentes) sobre la respuesta de la encuesta fue probablemente bajo eneste caso. Finalmente, una mayoría (56%) de los encuestados fueron usuarios internos implicando una categoríaMIS de aplicaciones fueron desarrollados para uso interno dentro de la organización, con los usuarios perteneciendoa 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 estudiocomo descrito más abajo. En cada caso hemos querido evaluar las creencias de los participantes acerca de si lasconstrucciones 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]. Eneste estudio, explicamos determinantes de la participación de los usuario como en TAM3, que explicacomportamiento del uso de sistema. Las investigaciones anteriores han medido la participación del usuario comoconstrucciones de un solo elemento o de varios elementos sobre la base de escalas tipo Likert [15]. Durante la fase1 de nuestro estudio, los participantes han mencionado cuatro perspectivas diferentes de calidad, es decir, lainteracción de participación de los usuarios, la naturaleza de la interacción, el nivel de compromiso, y la posturapsicológica. En consecuencia, se deriva un constructor compuesto de 4 elementos para medir la participación delusuario 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 endesacuerdo" 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 participenen el proyecto de desarrollo de software se mide por esta construcción. Los elementos de medición para la conductade intención ha sido adoptada de Davis [8], y luego modificado para que coincida con el contexto de estudio. Laconstrucció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 apartir 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 laescala de Likert como se mencionó anteriormente. 5
  6. 6. Interés de los usuarios: El interés de los usuarios es paralelo a “la construcción percibida del disfrute” (es decir elgrado a el cual la actividad de usar un sistema específico se percibe para ser agradable por derecho propio) deTAM3 ya que ambas construcciones implican un sentido de entusiasmo al ejecutar la actividad. La medida delinteré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 proporcionauna medida del grado de exigencia de esfuerzo real para llevar a cabo una tarea [10]. La evaluación del esfuerzo realestá relacionada con "la claridad del proceso", que permitirá una mejor evaluación de la situación. Con base en losresultados 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 proyectode los usuarios participantes (métrica “bien definida") , y una medida compuesta ("Procesos transparentes"). Lasopciones 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 larealización de una actividad. Sobre la base de la fase 1, la accesibilidad del usuario fue medida en términos deretardo 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 ytercer elemento, se les pidió a los encuestados que indicaran su nivel de acuerdo / desacuerdo sobre la escalaLikert.Percepción de la importancia del proyecto: Esto corresponde al constructor de "utilidad percibida" de TAM3. Similara esta última, la “percepción de la importancia del proyecto" ofrece un razonamiento detrás del beneficio decomprometerse con una actividad (en este caso, los beneficios asociados con la participación en el proyecto). Estose 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 unamedida del grado a el cual un individuo cree que el sistema realiza sus tareas del trabajo bien) de la construcción deTAM3. El grado del aumento de la “calidad de la salida” en lo referente a una cierta actividad se podría considerarcomo indicador de las ventajas probables que se asocian a la terminación correcta de esa actividad. Teniendo encuenta los aspectos monetarios y no monetarios de los beneficios del proyecto, fue construida una medida de 2elementos que consta de "utilidad general" y "reducción de Costos". Esto ayudaría a evaluar las creencias de losusuarios acerca de si el producto / servicio prestado por el proyecto de software sería útil a sus usuarios, y asistirá ala reducción de costes.Visibilidad del resultado: Esta construcción es análoga a la "demostrabilidad del resultado" (es decir, el grado en queun individuo cree que los resultados de la utilización de un sistema son tangibles, observables y comunicables) de laconstrucción de TAM3.La “demostrabilidad del resultado” proporciona la evalucación de los resultados que se facilitacon visibilidad creciente del resultado. La medida de la visibilidad del resultado esta constituida por los siguienteselementos: ○ 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 puntosde acuerdo / desacuerdo como se explicó anteriormente.Incertidumbre del proyecto: Esto se puede considerar como el antecedente de la construcción de "demostrabilidaddel resultado" de TAM3. Obviamente, en presencia de una mayor incertidumbre de"demostrabilidad del resultado" es 6
  7. 7. probable que sea menor. Las entrevistas con grupos principales sugieren la identificación de la incertidumbre delproyecto en términos de los riesgos asociados con el proyecto. Keil [16] ha propuesto medir el nivel de incertidumbreen 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 cuatrodimensiones. 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 visualizarcomo antecedente a la "demostrabilidad del resultado". El aumento en la complejidad es probable que influyanegativamente en la percepción de la medida en que el resultado podría ser comprensible para su destinatario. Lasdos 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 estabanestablecidas 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 unaevaluación del modelo estructural. Cabe recordar que los constructores en el modelo estructural no son directamenteobservables y tiene que ser evaluados en términos de medición asociada a la construcción (por ejemplo, laparticipación de los usuarios medidos por la calidad de la participación, la naturaleza de la interacción, el nivel decompromiso, la actitud psicológica). El modelo de ecuaciones estructurales se refiere a las relaciones entre lamedición de constructores como así también al modelo de medición. La evaluación del modelo consiste en losiguiente: ○ 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 pruebade las propiedades psicométricas de las escalas utilizadas para medir un constructor. Estima simultáneamente losparámetros del modelo estructural. Es decir, la magnitud y dirección de las relaciones entre el los constructores delmodelo [17]. La siguientes características de PLS lo hizo adecuado dadoel 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 fueutilizado para este análisis. Los coeficientes de trayectoria estimados del modelo se calcularon utilizando la 7
  8. 8. secuencia de arranque técnica [18]. Los resultados se discuten a continuación.5. RESULTADOS5.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 cargaronsuficiente en las construcciones correspondientes. Las cargas de cada uno de los elementos de medición semuestran en la Figura 2. Cada óvalo en el gráfico representa una construcción. Los rectángulos asociados con unaconstrucción muestran los elementos de medición que le corresponden y su medida correspondiente de carga. Enlas cargas de los 30 puntos de medición que se muestran en la Figura 2 se encontró que más de 0,50 fueronsignificativos 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 delmodelo de medición se evaluó mediante el cálculo de la fiabilidad compuesta (CR). Excepto la incertidumbre delproyecto (PU), el valor de CR para todas las otras construcciones estaban por encima del valor mínimo de 0,70 (nomostrado) [19]. El Cronbach alfa de las construcciones se encontró también en un rango aceptable, es decir, porencima 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,50AVE (no mostrado) [19], y por lo tanto se considera satisfactoria. La medida de validez discriminante también seencontró 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 elAVE. Sin embargo se ha conservado la construcción, ya que se deriva de evidencias de literaturas [16], y sucoeficiente 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 evaluadocon respecto a la significación estadística de los coeficientes de trayectoria estimados. Las relaciones significativasque surgieron del estudio se muestran con "**" en la figura 2.  Los resultados proporcionaron evidencias a favor delas 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. 9. resultados (H10) surgió como negativa. Esto puede explicarse considerando que la percepción de la incertidumbredel 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 losriesgos 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 noestadísticamente significativa (H9). La visibilidad del resultado fue determinada en nuestro modelo en términos devisibilidad de los productos a entregar del proyecto y de los plazos de proyecto. El resultado no mide la importanciade estos dos atributos que indican el estado del proyecto, sino que destaca que este factor no puede ser un factordeterminante a la hora de evaluar la importancia del proyecto. El rechazo de la hipótesis (H6) señala de manerasimilar a un conjunto diferente de los determinantes de la facilidad de involucrarse en el proyecto de lo que ha sidocapturada 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 facilidadpercibida de la participación del usuario (H7). Esto podría ser debido a que una alta proporción de los encuestadoseran 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 unobstá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 laparticipación del usuario) fue aceptada. De los usuarios que estaban interesados ​ ​ en participar, se espera que secomprometan a esta conducta por el simple hecho de hacerlo. Estos usuarios tienden a subestimar la dificultadasociada con la participación en el proceso porque les gusta lo que hacen. Por esta razón, la relación entre el interésdel usuario y la intención del usuario hacia la participación resultó ser mediada por la facilidad percibida de laparticipación del usuario.6. CONCLUSIÓN La importancia de la entender los potenciales facilitadores de la participación de los usuarios durante eldesarrollo de software es crítica debido al hecho de que la falta de participación de los usuarios es probable queresulte en los esfuerzos frustrados. Los resultados de esta investigación identifican ciertas condiciones ycaracterí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óndel usuario. La formación de la intención, a su vez se encuentra afectada por la importancia del proyecto para losusuarios, y cuánto se percibe del entorno del proyecto lo que favorece a la participación.  Estos dos últimas seencontraron nuevamente para ser impulsada por la percepción de los beneficios del proyecto y el nivel de interés delos usuarios, respectivamente. Los resultados ayudaron a explicar la transición de la participación de los usuarioscon el tiempo y el proceso, que aborda las limitaciones de estudios anteriores [3, 4] que veían la participación delusuario 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 seobtuvieron para este estudio, que podría limitar la fiabilidad de los resultados. Una tasa de respuesta baja y untamaño pequeño de muestra fueron tomados, por lo que este estudio puede limitar la confiabilidad de resultados. Seusaron las propias medidas reportadas, que son vulnerables a sesgos subjetivos. La posibilidad de errores demedición también pueden determinarse ya que algunas de las construcciones que se obtuvieron  fueron derivadas dela literatura divulgada, que en su mayoría se centró en el lado de la organización del proyecto, y por lo tanto lainterpretación de la organización de los usuarios es probable que sea diferente. Los efectos de la causalidad no sepueden explorar claramente debido a la naturaleza transversal del estudio. Los resultados también pueden tener unsesgo del muestreo porque la colección de datos fue restringida en la India solamente. Otras generalizaciones sólose 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 preferidasde definir y medir algunas de las construcciones capturadas en esta investigación (por ejemplo, la incertidumbre delproyecto, la claridad del proceso , el interés del usuario, etc), y por lo tanto, es probable que sea beneficioso para las organizaciones entérminos de identificar oportunidades de mejora. Los antecedentes significativos en la participación del usuario quesurgieron de los resultados son manijas específicas que se pueden utilizar para gestionar el nivel de participación delos usuarios en los proyectos. Además de abordar las limitaciones, las investigaciones futuras puede mirar en las relaciones nosignificativas 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 losfenómenos estudiados, lo que también se pueden explorar en proyectos futuros. 9
  10. 10. 7. REFERENCIAS[1] S. Kujala, "Effective user involvement in product development by improving the analysis of user needs", Behaviour andInformation 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 the24th 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 inInformation 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 fieldstudies", Management Science, 2000.[10] V. Venkatesh, and H. Bala, "Technology Acceptance Model 3 and a Research Agenda on Interventions", DecisionSciences, 2008.[11] Glaser, B., and Strauss, A., The Discovery of Grounded Theory: Strategies for Qualitative Research, Aldine PublishingCo., 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", Communicationsof 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 BusinessResearch, 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, UpperSaddle 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

×