A study of collaborative software development using groupware tools.

The experimental results of a collaborative problem solving and program development model that takes into consideration the cognitive and social activities that occur during software development is presented in this paper. This collaborative model is based on the Dual Common Model that focuses on individual cognitive aspects of problem solving and programming. The Dual Common Model, shown to improve the problem solving and programming skills of individual programmers (Deek, 1997), was extended to integrate groupware needs. The model was tested using a groupware tool called Groove. The study includes four conditions: Groove and the collaborative model, Groove alone, the collaborative model alone, and neither groove nor the collaborative model. The subjects were students of a graduate course in object oriented programming at the New Jersey Institute of Technology.

**********

INTRODUCTION

Problem solving is fundamental to software development. An extensive literature review was performed (DeFranco, 2002; DeFranco & Deek, 2002) and the results showed that a comprehensive model that took into consideration cognitive issues involved in a group collaborating during problem solving and program development was missing. A collaborative model was developed (DeFranco, Deek, McHugh, & Van de Walle, 2002; DeFranco, 2002) and an experiment to measure the effectiveness of the collaborative problem solving model coupled with groupware tools was conducted. The results are presented in this paper.

THEORY

The collaborative problem-solving model (DeFranco, et al., 2002; DeFranco 2002) takes into consideration the cognitive and collaborative processes of a collaborative software development group while addressing the psychological and sociological factors of teamwork. The model explicitly addresses the communication, collaboration, and coordination requirements of a group. A six-stage model accomplishes this with each stage having three phases. Each phase is made up of a collaborative structure that contains modality, collaborative processes, side effects, and administration.

Collaborative modality (CM) is a tool that can accomplish the collaborative processes of a phase. For example, the collaborative modality, when developing a preliminary mental model, incorporates tools that can continue the brainstorming activities that occurred during the development of the preliminary problem description. A message board or activity log could be of use where team members would post their understanding of the problem and each member of the team would be required to vote on the correct model descriptions of the problem. The main purpose of an activity log is to keep a summary of digital records during team member interactions (Dennis, Nunamaker, & Vogel, 1991).

An example of collaborative processes in a stage is communication. In order for the communication process to be a success, each team member's solution must be verbalized and understood by the other team members in order for it to have a fair evaluation. This can either occur as face-to-face communication or publication style communication where the group members do not necessarily know each other and communicate by broadcasting information to the entire group. Team members initiating an elaboration activity can assist the communication process. Elaboration activities should occur when any group member proposes a new solution to the problem under study. All of the proposed solutions and evaluations also need to be coordinated in order for the next collaborative process of negotiation and voting to occur. Using both process templates and process structure can facilitate coordination. Process templates can simplify the use of a group tool during activities such as brainstorming and voting etc. (Nunamaker, Briggs, & Mittleman 1996).

Cohesive groups tend to exhibit higher levels of communication overall, as well as higher task-related and non-task related communication (Dennis, Easton, Easton, George, & Nunamaker, 1990). Many of these side effects may be a result of organizational behavior norms. These norms are preexisting behavioral characteristics of a group (Dennis, Nunamaker, & Vogel, 1991).

An example of collaborative administration during a phase is when the team leader facilitates the problem understanding process. The team leader should lead the group by explicitly representing the goal of the group (Whitworth, Gallupe, & McQueen, 2000). This would include initiating the group discussion; whether it is on-line or face-to-face, every team member would be required to participate and vote on the correct verbalizations of the problem.

METHODOLOGY/DATA COLLECTION

The experiment lasted 3 weeks including a 3-day training session. The subjects were randomly placed into groups of four; then each group was placed in one of the four conditions.

Data were collected from two main sources: group-written documents rated by expert judges and a post-task questionnaire presented at the end of the experiment. An inter-rater reliability check was performed with a bivariate Pearson 2-tailed test. It was found that there was a significant correlation at the .01 level between the two judges (r = .932, p < .01). The results of a Paired Samples t test, which was also performed, showed no significant difference between the judges (.503).

The experiment took place in the spring 2002 semester. The subject groups were placed into one of the four conditions:

1. Access to Groove AND to the model

2. Access to Groove AND no model access

3. E-mail AND access to the model

4. E-mail AND no model access

There were 174 subjects who completed the experiment, equating to 12 groups in condition 1, 10 groups in condition 2, 11 groups in condition 3, and 11 groups in condition 4. All subjects were students of graduate C++ and JAVA courses.

EXPERIMENT HYPOTHESES ANALYSIS/RESULTS

Twelve 2X2 ANOVAs were performed on the data collected as well as a Factor Analysis on post-task questionnaire data. The results were compared against the hypotheses formulated; they are shown in Table 1 and presented in the following sections.

Solution Creativity Results

The solution creativity variable was measured by the judges' evaluation of the solution plan document that was written by each group. The results showed no significance with any of the independent variables as shown in Table 2. Therefore, hypotheses H1a, H1b, and H1c were not supported.

Solution Quality Results

The solution quality variable was measured by the judges' evaluation of the solution plan document that was written by each group. The results, shown in Table 3 showed no significance with any of the independent variables. Therefore, hypotheses H2a, H2b, and H2c were not supported.

Questionnaire Evaluation

The post-task questionnaire was evaluated via a Factor Analysis and Chronbach's Alpha to determine the factors; then an ANOVA was done on the resulting scales. The results from the Factor Analysis, using a factor loading of .55 or greater and an Eigen value greater than 1, were three scales. Scale one included questions 1, 2, 3, 4, 5, 6, 7, 9, and 10. It had an Eigen value of 6.73, explaining 48.1% of the variance un-rotated. Scale one, when rotated, had an Eigen value of 4.2, explaining 30% of the variance. Scale two included questions 2, 8, 10, 12, and 14. It had an Eigen value of 1.34, explaining 9.5% of the variance un-rotated. Scale two, when rotated, had an Eigen value of 3.2, explaining 22.6% of the variance. Scale three included questions 11 and 13. It had an Eigen value of 1.03, explaining 7.4% of the variance. Scale three, when rotated, had an Eigen value of 1.7, explaining 12.4% of the variance. The three scales combined accounted for 65.0% of the variance.

Further analyzing the results, it was logical to only use scale one for the satisfaction variable since it included every satisfaction question except question eight. It was also logical to use scale three for task validation since it included two of the four task validation questions and no satisfaction questions. A Chronbach's Alpha evaluation was also performed resulting in a value of .9. This value showed a high internal consistency for the questionnaire.

To complete the analysis, an ANOVA was performed on the satisfaction questions that resulted from the Factor Analysis. The results, which are shown in Table 4, showed no significance for this variable. Therefore, H3a, H3b, and H3c were not supported.

An ANOVA was also performed on the Task Validation questions that resulted from the Factor Analysis. The results, which are shown in Table 5, showed no significance for this variable.

Problem Understanding Results

The problem-understanding variable was measured by the judges' evaluation of the problem formulation document that was written by each group. The results of an ANOVA evaluation of the data showed a .017 significant difference of the problem understanding between subjects exposed to the collaborative model and the subjects not exposed to the model. Where subjects that used the collaborative model had a higher problem understanding than the subjects that did not have access to the collaborative model. Table 6 shows the results from an ANOVA evaluation of the problem understanding dependent variable.

These results supported the main effect, hypothesis H4b. Hypothesis H4a and H4c were not supported.

Number-of-Alternatives Results

The number-of-alternatives variable was measured by the judges' evaluation of the solution plan document that was written by each group. The results of an ANOVA evaluation test showed an interaction significance of .045 for access to the collaborative model and Groove. Table 7 shows that the groups with access to the collaborative model and no access to Groove presented the most solution alternatives for the task. The interaction occurred with the groups having access to Groove and no access to the collaborative model and the groups with access to the model and no access to Groove.

The interaction effect was further evaluated by doing a Post Hoc Bonferroni procedure to determine where the interactions lie. Six independent t tests were performed. Four of the six possible tests showed significance.

The first significant result was the analysis of condition 1 (tool + model) with condition 2 (tool + no model). The result from the t test was an F value of 6.47 translating to a significance of .02.

The second significant result was between condition 1 (tool + model) and condition 3 (no tool + model). The result from the t test is an F value of 6.1 translating to a significance of .022.

The third significant result was between condition 2 (tool + no model) and condition 4 (no tool + no model). The result from the t test was an F value of 5.57 translating to a significance of .029.

The fourth and final significant result was between condition 3 (no tool + model) and condition 4 (no tool + no model). The result from the t test was an F value of 5.2 translating to a significance of .034.

These results indicate that either the tool or the model alone was significantly better. However, the combination or the absence of both the tool and model was not significantly better. Hypothesis H5c was supported.

Quality-of-Solution Planning Results

The quality-of-solution planning variable was measured by the judges' evaluation of the solution plan document that was written by each group. The results of an ANOVA evaluation of the data showed a .007 significant difference in the quality of solution planning between subjects exposed to the collaborative model and the subjects not exposed to the model. Table 8 shows the subjects that used the collaborative model scored higher for the quality-of-solution planning than the subjects that did not use the model.

These results supported the main effect, hypothesis H6b. Hypotheses H6a and H6c were not supported.

Summary of Hypotheses Analysis

Table 1, shown previously, showed a summary of the hypotheses results of the experiment. In summary, out of the six hypotheses, zero was supported for the tool, two were supported for the model, and one was supported for the interaction. The hypotheses that most represented the collaborative model were H1, H2, H4, H5, and H6. Two of these proved significant for the model: quality-of-solution planning and problem understanding. One proved a significant interaction that showed that either the tool or model alone was significantly better when creating solution alternatives. The hypotheses supported by the tool and the hypotheses that supported additional interactions were related to the e-mail statistics.

DISCUSSION, CONCLUSIONS, AND FUTURE WORK

This section concludes this paper with a summary of the evaluation results presented in the previous section. This summary includes a discussion of the experimental results and their implications. Questions will be answered as to why certain variables had positive results and why others did not. In addition, the implications of the experimental results will also be compared to the collaborative model.

This section will also include a discussion of the various research contributions this research provided. Finally, a conclusion with proposed enhancements to the experimentation of the collaborative problem solving and program development model, proposed further experimentation, and future work plans will be provided.

Evaluation Results

Taken as a whole, this experiment proved some benefits of implementing a structured framework during the collaborative problem solving and program development process. This section will summarize the supported hypotheses of the experiment as well as attempt to explain the unsupported hypotheses.

Solution Creativity Hypothesis. Solution creativity is the first of the three totally unsupported dependent variables in that there were no main effects for either the tool or the model or an interaction effect. The judge's evaluation of creativity did not show a significant difference between the conditions. This could be because the task given to the subjects in this experiment (supermarket system modeling, a well-structured task with components pre-specified) may not have produced sufficient variance in creativity. In other words, the task was so well structured that it resulted in similar solutions by the subjects in the various conditions. To increase the variance for creativity in the experimental conditions, the experimental task difficulty, novelty, or ambiguity could be increased. The increased task difficulty would result in a larger range of solutions for the task.

Solution Quality Hypothesis. Solution quality is equally affected by the short training period as well as the absence of a training task. The teams with Groove access may have been focusing more on the new tools available to them and not on a quality solution to the task. The teams with CM access may not have been able to fully utilize the model since it was the first time the model was seen by the subjects.

The unsupported variables of this experiment, creativity and quality, are also consistent with research of software requirements creation (Ocker, Hiltz, Turoff, & Fjermestad, 1995). These results stated that using a "problem solving approach did not significantly impact creativity or quality."

Solution Satisfaction Hypothesis. Solution satisfaction was also an unsupported dependent variable. The lack of support could be attributed to insufficient training time prior to the experiment. In the training period of the experiment, the subjects were expected to download the Groove software, install it, and create a workspace for their team. This could have been overwhelming to some of the team members and effectively could have slowed down the connection process with their team. This would create dissatisfaction for the overwhelmed team members as well as the team members who were waiting for their team to connect. In addition, there was no training task; therefore; teams with access to the CM were working with a model they had never had the opportunity to use prior to the experiment, possibly creating another overwhelming situation. Adding a training task might remedy that situation.

An experiment on the CyberCollaboratory (Dufner, Kwon, Park, & Qing, 2002) also produced similar results for efficiency, coordination, fairness, and satisfaction. This experiment suggested subjects in a condition with access to the CyberCollaboratory system felt the process was less efficient, coordinated, fair, and satisfying. It was suggested (Dufner, Kwon, Park, & Qing, 2002) that this result was possibly due to the insufficient training time, combined with a short amount of time using the tools, for a fairly simple group training task.

Problem Understanding Hypothesis. The resulting data from the problem formulation document showed that subjects having access to the collaborative model had a greater understanding of the problem they were attempting to solve than did the groups that did not have access to the collaborative model. Problem understanding is specifically associated with the first stage of the collaborative model that included the preliminary problem description, preliminary mental model, and structured problem representation phases. The subjects were able to show a clear understanding of the problem description; they were able to determine goals, givens, and unknowns, and they were able to extract facts from the problem description and organize them in order to better understand the problem. Specifically, the subjects were instructed to interpret and verbalize the problem. If they were in a condition that had access to Groove they were able to use a brainstorming or discussion tool to verbalize their problem understanding with their team members. If they were not assigned a condition that gave them access to Groove, they accomplished their verbalization through e-mail. Following the verbalization task, team members were to agree upon a problem description in which the entire team would follow.

The team's problem-understanding success was further enhanced by the team's answering of a few questions regarding the problem; these included: What is the goal? Do the goals require clarification? Are there any other explicit or implicit problem requirements? What are the givens? What are the unknowns? Are there any conditions and constraints? These answers were organized and used to begin the design and planning of a solution. Lack of support for the tool main effect may have had to do with either the learning curve factor in using a new tool or, possibly, with Groove's lack of facilitating the problem understanding tasks in the CM.

Number-of-Alternatives Hypothesis. The number-of-alternatives variable, measured by the solution plan document, showed a significant interaction effect. Further analysis of the interactions showed that the number of alternatives was significantly higher in teams that had access to the collaborative model alone or had access to Groove alone. Teams who had access to the combination of Groove and the collaborative model or who were involved in the condition where both Groove and the collaborative model were absent were found to have created significantly fewer alternatives. This could be explained by the learning curve factor with both Groove and the collaborative model. Subjects who had to learn both might have had a slight disadvantage compared to those who only had to learn either a new tool or the new model.

Adding time and a simple task to the training session could possibly remedy this problem. Modification of the training session will be discussed further in the next section of this paper. The success of the conditions with only access to the tool could be explained by the increased ability to communicate, such as having access to a brainstorming tool as well as a chat tool. The teams with access to only the collaborative model may have had success because of the explicit tasks involved in using the collaborative model, which encourage a well thought out solution where many alternatives are discussed to determine that the correct solution plan was chosen.

Quality-of-Solution Planning Hypothesis. The resulting data from the solution plan document showed that subjects who had access to the collaborative model performed better on this step than subjects who did not have such access.

The success of the model for this variable may have to do with the specific planning tasks, such as the decomposition of the task into specific sub goals and the demonstration of a plan for accomplishing this task; this was suggested by the model. The lack of support for the tool main effect may have to do with the fact that the tools associated with Groove were too complicated to learn in the limited amount of time given for the experiment.

Results Overview. To summarize the results, the hypotheses variables that most represented the collaborative model were problem understanding, quality-of-solution planning, creativity, quality, and number of alternatives. Two of these proved significant for the model: quality-of-solution planning and problem understanding. One, number-of-alternatives, proved a significant interaction; this showed that either the tool or model alone was significantly better when creating solution alternatives.

It is probable that the lack of support for the tool (Groove) with the hypotheses related to the model has to do with the learning curve of using a new tool. Adding a simple training task, which would be performed during the training period, to the experiment could have increased the hypothesis support for Groove. This task would have acted as a practice problem to familiarize the team with Groove and all of its features. More time would have been required for this addition; however, adding a practice problem may have increased the quality, creativity, and satisfaction variables.

Another possible cause of the lack of Groove support could be that the model and tool were not similar enough. Subjects in the condition where they had access to both the tool and the model had to learn both, subsequently increasing the apparent learning curve. The reason Groove was chosen was to facilitate certain aspects of the model. Further study of tool assistance with the CM as possible future work will be discussed in the next section.

Summary of Research Contributions

This research tested the framework for a collaborative problem solving and program development model that detailed the cognitive processes and the social activities that occur during problem solving and program development (DeFranco, Deek, et al., 2002; DeFranco, 2002). This model has demonstrated improvement of the output of a group attempting to use software to solve a problem and the success of such a model.

In the past, most groupware systems have focused on the communication aspect of collaboration but not on the coordination and cognitive issues that need to be addressed during problem solving and software development. The CM does address such issues by detailing the cognitive activities and collaborative structure in each phase of the model. Previous studies in this area have only examined software requirement development with the use of different modes of collaboration (Ocker, Hiltz, Turoff, & Fjermestad, 1995; Ocker 2001).

The experiment performed to test the CM considered a much larger aspect of the problem solving and software development process. The focus was on the first two stages of problem solving and software development: problem formulation and solution planning. Several objectives have been accomplished by this research:

1. The cognitive processes and collaborative structure required for the six stages of collaborative problem solving and program development were defined and detailed (DeFranco, Deek, et al., 2002; DeFranco, 2002). These cognitive processes and the collaborative structure take into consideration the psychological and sociological issues present during problem solving and program development collaboration. Collaborative problem solving is characterized by the cognitive processes that it identifies for problem solving and by the collaborative structure it utilizes. A collaborative structure was defined both by the modality of the collaboration and the dynamics of the group. The modality of collaboration refers to the variety of possible interaction modes, ranging from chat to asynchronous messaging. The group dynamics of a collaboration encompasses the processes that define the collaboration: negotiation, scheduling, coordination, integration, acceptance, etc.; the side effects of these collaborative processes: cognitive bias, conflict resolution, group cohesion, distributed learning, etc; the administration of these collaborative processes: task initiation, delegation of functions, subcomponent integration, on going evaluation, etc; and the management of side effects.

2. An extensive literature review (DeFranco, 2002; DeFranco, Deek, 2002), previously published, beginning with a discussion of individual problem solving prior to discussing the background literature on collaborative problem solving, was presented. Additional background literature on groupware systems, general groupware tools, and groupware tools specific for problem solving and software development was also presented. This review determined the lack of collaborative problem solving models and tools to enhance the problem solving and program development needs of teams.

3. A review and case study of groupware tools was performed and critiqued (DeFranco, 2002). This review resulted in first determining that a tool available to assist in the entire collaborative problem solving and program development process did not exist. Secondly, the review resulted in finding a tool to facilitate the collaborative modality of the model during the experimentation with the collaborative problem solving and program development model.

4. Results of an experiment showing the enhancement of solution planning and problem understanding for subjects using the collaborative model were detailed. In addition, a few of the measured variables of this experiment also showed results similar to previous studies that experimented with groupware tools.

Future Work

Future work should consist of thorough experimentation on the remaining four stages of the collaborative problem solving and program development model. This should further show the benefits of the CM during the solution design, solution translation, solution testing, and solution delivery stages of the model. This type of experiment would be rather extensive in that an entire project from problem understanding to code implementation would be necessary. At least 6 to 8 weeks of time should be allocated to test these stages of the model. The allocated experiment time would be dependent upon the complexity of the problem. It should be noted again that having a more complex problem could create the right amount of variance for the measured creativity variable.

In addition to testing the remaining stages of the CM, modifying the training portion of the experiment by adding a simple training task and additional time to the training session may show positive results when measuring the quality, creativity, and satisfaction variables. The extra training time would also lessen the effects of the learning curve that occurred with using Groove and the CM. The extra training time may also increase satisfaction among the subjects given that satisfaction was decreased due to learning curve issues and the possible feeling of being overwhelmed, which may have occurred because of learning a new tool and model.

Future work should also consist of integrating the collaborative model with existing groupware tools such as Groove. This would eliminate a portion of the learning curve during the experiment and ultimately during the use of the tool by software developers.

The combination of Groove and the CM would only be prudent if positive results from the tool main effects of the hypotheses resulted from testing the remaining stages of the CM. If the tool main effects do not show positive results, a new collaborative tool should be designed that has a closer resemblance to the collaborative modality of the CM. This tool could contain the necessary technology to facilitate the collaborative dynamics imbedded in each phase of the CM.

A newly designed tool would have a higher probability to facilitate the experimental results of the CM, such as problem understanding and solution planning--and possibly the non-positive experimental results, such as creativity, quality, and satisfaction. This tool could take into consideration the group dynamics of software development and facilitate the processes that define the collaboration; these include negotiation, scheduling, coordination, integration, acceptance, etc. The tool could also be designed to eliminate the negative side effects of collaboration such as cognitive bias and conflict resolution and enhance the positive side effects such as group cohesion and distributed learning.

CONCLUSIONS

Contemporary system developers work in environments where projects require a team effort. This fact implies that collaboration or group problem solving is an expected skill for these software and systems engineers. Factors driving this implication include the scale of contemporary engineering projects that necessitate collaborative development, the logistical difficulties of divergent work schedules, the geographical dispersion of expertise, and the availability of platform-independent communications provided by the Web.

Collaborative development has a variety of advantages beyond alleviating logistical difficulties; these range from demonstrable improvements in design efficiency, effectiveness of problem specification, substantial benefits from group learning, the reliability afforded through group understanding of the problem and the current state of the project, to other advantages as indicated in our analysis. By integrating the problem solving underpinnings of collaborative development, the technological, psycho-social, and cognitive factors that arise in these systems, the requirements needed for collaboration during software development have been identified.

Table 1 Summary of Hypotheses Results

HYPOTHESIS                                                   RESULT

H1a. Teams working with the tools will produce more          Unsupported
     creative solutions than teams working without tools.
H1b. Teams having access to the CM will produce more         Unsupported
     creative solutions than teams working under the
     condition without the CM.
H1c. When evaluating solution creativity, a positive         Unsupported
     synergistic effect will occur between the tools and
     the CM.
H2a. Teams working with the tools will produce higher        Unsupported
     quality solutions than teams working without tools.
H2b. Teams with access to the CM will produce higher         Unsupported
     quality solutions than teams working under the
     condition without the CM.
H2c. When evaluating solution quality, a positive            Unsupported
     synergistic effect will occur between the tools and
     the CM.
H3a. Satisfaction will be higher in the teams with tools     Unsupported
     than for teams working without tools.
H3b. Satisfaction will be higher in teams having access to   Unsupported
     the CM than in teams working under the condition
     without the CM.
H3c. When evaluating satisfaction, a positive synergistic    Unsupported
     effect will occur between the tools and the CM.
H4a. Teams having access to the collaborative tools will     Unsupported
     show superior understanding of the problem as
     demonstrated by their ability to clearly and correctly
     state problems and extract problem facts better than
     teams without tool access.
H4b. Teams having access to the CM will show superior        Supported
     understanding of the problem as demonstrated by their
     ability to clearly and correctly state problems and
     extract problem facts better teams without CM access.
H4c. When evaluating problem understanding, a positive       Unsupported
     synergistic effect will occur between the tools and
     the CM.
H5a. Teams working with tools will generate more             Unsupported
     alternatives than those teams working without tools.
H5b. Teams having access to the CM will generate more        Unsupported
     alternatives than teams working under the condition
     without the CM.
H5c. When evaluating the number of alternatives generated,   Supported
     a synergistic effect will occur between the tools and
     the CM. It was foundthat either the tool or the model
     alone was significantly better. However, the
     combination or the absence of both the tool and model
     was not significantly better.
H6a. Teams having access to the collaborative tools will     Unsupported
     show higher quality solution planning as demonstrated
     by their ability to provide detailed and clear plans
     and complete goal refinements and representation of
     facts better then teams working under the condition
     without tool access.
H6b. Teams having access to the CM will show higher quality  Supported
     solution planning as demonstrated by their ability to
     provide detailed and clear plans and complete goal
     refinements and representation of facts better then
     teams working under the condition without the CM.
H6c. When evaluating solution planning quality, a positive   Unsupported
     synergistic effect will occur between the tools and
     the CM.

Table 2 Solution Creativity Results

         MODEL       NO MODEL    ALL

TOOL     Mean: 7.63  Mean: 6.7   7.163
         SD: .933    SD: 2.18
NO TOOL  Mean: 7.14  Mean: 7.41  7.273
         SD: 1.47    SD: 1.0
ALL      7.38        7.06        Grand Mean: 7.22

Tools: F = .064; p = .802 Model: F = .557; p = .460 Tools X Model: F =
1.88; p = .178

Table 3 Solution Quality Results

         MODEL       NO MODEL    ALL

TOOL     Mean: 7.71  Mean: 7.35  7.53
         SD: .941    SD: 1.6
NO TOOL  Mean: 6.91  Mean: 6.91  6.91
         SD: 1.67    SD: 1.77
ALL      7.31        7.13        Grand Mean: 7.22

Tools: F = 1.83; p = .184 Model: F = .153; p = .698 Tools X Model: F =
.153; p = .698

Table 4 Satisfaction Results

         MODEL        NO MODEL     ALL

TOOL     Mean: 49.43  Mean: 51.65  50.54
         SD: 10.52    SD: 8.57
NO TOOL  Mean: 47.88  Mean: 51.39  49.64
         SD: 11.69    SD: 8.85
ALL      48.66        51.52        Grand Mean: 50.09

Tools: F = .32; p = .57 Model: F = 3.23; p = .07 Tools X Model: F =
.674; p = .68

Table 5 Task Validation Results

         MODEL        NO MODEL     ALL

TOOL     Mean: 9.11  Mean: 9.62   9.37
         SD: 3.46    SD: 3.34
NO TOOL  Mean: 9.6   Mean: 10.26  9.93
         SD: 2.77    SD: 2.84
ALL      9.36        9.94         Grand Mean: 9.65

Tools: F = 1.29; p = .26 Model: F = 1.39; p = .241 Tools X Model: F =
.02; p = .88

Table 6 Problem Understanding Results

         MODEL       NO MODEL    ALL

TOOL     Mean: 6.25  Mean: 4.73  5.49
         SD: 2.27    SD: 2.67
NO TOOL  Mean: 7.25  Mean: 4.89  6.07
         SD: 1.83    SD: 3.36
ALL      6.75        4.81        Grand Mean: 5.81

Tools: F = .553; p = .462 Model: F = 6.196; p = .017 Tools X Model:
F = .288; p = .594

Table 7 Number-of-Alternatives Results

         MODEL       NO MODEL    ALL

TOOL     Mean: 1.7   Mean: 1.6   1.65
         SD:  .39    SD: 1.35
NO TOOL  Mean: 1.82  Mean: 1.18  1.5
         SD:  .98    SD:  .40
ALL      1.76        1.39        Grand Mean: 1.58

Tools: F = .203; p = .655 Model: F = 154; p = .697 Tools X Model:
F = 4.27, p = .045

Table 8 Quality-of-Solution Planning Results

         MODEL       NO MODEL    ALL

TOOL     Mean: 7.0   Mean: 4.3   5.65
         SD: 1.81    SD: 2.87
NO TOOL  Mean: 6.64  Mean: 5.23  5.94
         SD: 1.87    SD: 2.85
ALL      6.82        4.77        Grand Mean: 5.79

Tools: F = .154; p = .697 Model: F = 8.172; p = .007 Tools X Model:
F = .807; p = .375

Acknowledgments 

This work was supported by New Jersey Information-Technology Opportunities for the Workforce, Education and Research (NJ I-TOWER), a New Jersey Institute of Technology (NJIT) project funded by the New Jersey Commission on Higher Education "High Technology Workforce Excellence Grant" initiative, award # 01-801020-02.

References

Deek, F. P. (1997). An integrated environment for problem solving and program development. Doctoral dissertation, New Jersey Institute of Technology.

DeFranco-Tommarello, J., Deek, F., McHugh, J., & Van de Walle, B. (2002). A collaborative problem solving and program development model. In Proceedings of the International Conference on Software Engineering Research and Practice (pp. 481-487). Las Vegas, NV.

DeFranco-Tommarello, J. (2002). Collaborative problem solving and program development model. Doctoral dissertation, New Jersey Institute of Technology.

DeFranco-Tommarello, J., & Deek, F. (2002). Collaborative software development: A discussion of problem solving models and groupware technologies. In Proceedings of 35th Annual Hawaii International Conference on System Sciences. Los Alamitos, CA: IEEE Computer Society Press.

Dennis, A. R., Easton, A. C., Easton, G. K., George, J. F., & Nunamaker, J. F. (1990). Ad hoc versus established groups in an electronic meeting system environment. In Proceedings of the 23rd Hawaii International Conference on System Sciences, Vol 3, (pp. 23-29). Los Alamitos, CA: IEEE Computer Society Press.

Dennis, A. R., Nunamaker, J. F., & Vogel, D. R. (1991). A comparison of laboratory and field research in the study of electronic meeting systems Journal of Management Information Systems, 7(3), 107-135.

Dufner, D., Kwon, O., Park, Y., & Qing, P. (2002, January). Asynchronous team support: Perceptions of the group problem solving process when using a CyberCollaboratory. In Proceedings of 35th Annual Hawaii International Conference on System Sciences: Vol. 1 (pp. 3b). Los Alamitos, CA: IEEE Computer Society Press.

Nunamaker, J., Briggs, R., & Mittleman D. (1996). Lessons from a decade of group support systems research. In Proceedings of 29th Annual Hawaii International Conference on System Sciences: Vol. 3 (pp. 418-427). Los Alamitos, CA: IEEE Computer Society Press.

Ocker, R., Hiltz, S. R., Turoff, M., & Fjermestad, J. (1995). The effects of distributed group support and process structuring on software requirements development Teams. Journal of Management Information Systems, 12(3), 127-153.

Ocker, R. (2001). The relationship between interaction, group development, and outcome: A Study of Virtual Communication. In Proceedings of 34th Annual Hawaii International Conference on System Sciences. Los Alamitos, CA: IEEE Computer Society Press.

Whitworth, B., Gallupe, G., & McQueen, R. (2000). A cognitive three-process model of computer-mediated group interaction. Group Decision and Interaction, 9, 431-456.

JOANNA DEFRANCO-TOMMARELLO AND FADI P. DEEK

New Jersey Institute of Technology, USA

[e-mail] 

[e-mail]