Diese Präsentation wurde erfolgreich gemeldet.
Die SlideShare-Präsentation wird heruntergeladen. ×

Determinants of user involvement in software projects

Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Wird geladen in …3
×

Hier ansehen

1 von 11 Anzeige
Anzeige

Weitere Verwandte Inhalte

Andere mochten auch (20)

Ähnlich wie Determinants of user involvement in software projects (20)

Anzeige

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

×