Confirming the Influence of Educational ... - Semantic Scholar

2005 ACM Symposium on Applied Computing

Confirming the influence of educational background in pair-design knowledge through experiments Gerardo Canfora°, Aniello Cimitile°, Felix Garcia*, Mario Piattini*, Corrado Aaron Visaggio° °RCOST-Research Centre on Software Technology University of Sannio Palazzo ex-Poste, viale Traiano, 1 82100 Benevento, Itay {canfora, cimitile,visaggio}@unisannio.it *Alarcos Research Group, University of Castilla-La-Mancha Paseo de la Universidad, 4 13071 Ciudad Real, Spain {Felix.Garcia, Mario.Piattini}@uclm.es

ABSTRACT

a wide recognized strategic key factor for business success. Two approaches are usually adopted when dealing with knowledge management. The first one refers to the notion of knowledge as object, to be created, modified, stored, and re-used. It addresses usually the explicit knowledge, that can be codified in rules, data, formulas, and procedures, and transferred by using diverse kinds of documentation. The second one considers knowledge in a cognitive dimension, consisting of beliefs, ideas, values, schemata, and mental models. It refers to tacit knowledge, that is personal experience and capability used to solve problems and, for its intrinsic nature, it is hard to codify and consequently to transfer, too. So far, Software Engineering concentrated efforts in defining tools and processes to optimize formalization, elaboration and sharing of explicit knowledge. Melnik and Maurer [12] identified some concerns and limits related to such an approach for knowledge management. Documentation is not easy to produce and maintain and has a low communication bandwidth. They conclude that “face-to-face channels offer the prospect of richer communication because of the ability to transmit multiple cues[…]important when there are high levels of equivocality (ambiguity) and uncertainty.” Communication and collaboration are key features of pair programming. Pair programming [16] is a practice of extreme programming [2], where two programmers, working side by side, develop the same piece of code. One programmer, usually named ‘driver’, actively writes the code while the other programmer, usually named ‘observer’, identifies tactical and strategic defects and issues. The roles are periodically switched. A claimed benefit of pair programming is that it fosters knowledge leveraging between the two programmers, particularly tacit knowledge. This is confirmed by Cockburn [7]: the most effective form of communication is two people discussing at a whiteboard, that is two people sharing the same physical space and instruments. Williams [19] found as an initial exploration that pair programming can help to reduce the effect pointed out in the Brook’s law [3]. It asserts “adding manpower to a late software project makes it later”, because it increases training costs, assimilation time (time lost learning about the project), and intercommunication overhead (work required to communicate,

The sharing of tacit knowledge is a strategic factor for the success of software process, from a number of perspectives: training, project assimilation, and reducing noise in knowledge transfer. Pair programming is supposed to be a practice suitable for this purpose. Unfortunately, the building of tacit knowledge is determined by factors that are difficult to isolate and capture because they concern personal attitude and capability. Thus, we have focused on the possible causes forming the individual ability, that can be isolated and studied, such as the individual education background. We have applied the practice of working in pairs to the design phase. We have made an experiment and a replica in academic environment, in order to understand the relationship between the building of knowledge through the practice and the individual background. In this paper we discuss the replica and compare the results with the first experiment’s ones.

Categories and Subject Descriptors D.2.9 [Software Engineering]: Management – life cycle, programming teams, software process models.

Keywords Agile development, pair programming, knowledge management.

1. INTRODUCTION Governing the dynamics of knowledge building and sharing is

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. SAC’05, March 13-17, 2005, Santa Fe, New Mexico, USA. Copyright 2005 ACM 1-58113-964-0/05/0003…$5.00.

1478

formally or informally, among the team members). Pair programming allows new team members to learn more about the overall project. Standing such considerations, and because system designing relies on tacit knowledge, the practice of working in pairs could facilitate the process of building design knowledge when contrasted with working as singletons. Similarly to pair programming, we name “pair designing” the practice where two designers work side by side at the same design document; one of the two actively edits the document whereas the second performs continuous review. In this paper we present the replica of an experiment, made at the University of Sannio in Italy, aiming at understanding the relationship between pair designing and knowledge building. The replica was realized at the University of Castilla-La-Mancha in Spain, with the purpose of confirming the findings of the previous experiment. The building of tacit knowledge through the practice is affected by a huge amount of factors difficult to capture and measure, such as personal attitude, capability, experience. We focus on one of these factors: the individual education background, in terms of classes of graduation. The overall research goal is: to analyze a design task with the purpose of evaluating how individual background affects the knowledge built with pair designing from the viewpoint of the designer, in the context of an actual student project. The paper proceeds as follows: section 2 presents the related work; section 3 discusses the first experiment; section 4 shows the replica design and section 5 discusses the results; finally, section 6 draws the conclusions.

Recently, the target of pair programming investigation is turning to learning and knowledge transfer. Williams and Kessler [15] found that pair programming fosters knowledge leveraging between the two programmers, particularly tacit knowledge. The authors affirm that this is due to discussing strategies and matters as they arise. In [5], authors investigate, throughout an experiment, which are the knowledge needs to be addressed in order to implement effectively pair programming, when pair’s components are distributed. Williams and Upchurch [17] examine the ways pair programming may enhance teaching and learning in computer science education. Students were able to complete programming assignments faster, with higher quality, and appeared to learn faster. This study addresses explicitly the relationship between pair programming and learning, proposing the hypothesis that a correlation may exist. McDowell et al. [11] investigate the effects of pair programming on student performance in an introductory programming class. The results show that students who worked in pairs produce better programs. These results are enforced by some experiences in using pair programming coupled with individual written reports in introductory computer science courses. This research is reported in [14]and basically explores the perception of pair programming from student perspective as beneficial to their learning. Students perceived pair programming as valuable to their learning. Forsythe et al. [8], describe the development and preliminary validation of tools to assess tacit knowledge for leadership at three organizational levels of US Army. This work provides good suggestions on how capturing tacit knowledge for experimentation. The main concerns emerging from the state of the art are two: first, the greatest part of the study involves students rather than professionals; second, the analyses accomplished are mainly qualitative instead of quantitative. To our best knowledge, however, no study has been published that addresses pair designing.

2. RELATED WORK The current work is part of a family of experiment, aiming at evaluating the relationship between the practice of working in pairs applied to any phase of software process and the knowledge building about the ‘big picture’ of the system. The results of the first experiment about the relationship between pair designing and knowledge leveraging were discussed in [4]. Two main outcomes were obtained. First, along all the experiment subjects who worked in pair showed a greater knowledge with respect to those who worked as singletons. Second, the knowledge building was more stable for pairs than for singletons: the knowledge growth of pairs can be predictable and repeatable within certain limits.

3. THE FIRST EXPERIMENT: DESIGN AND RESULTS In this section the first experiment is summarized in order to understand the context of the replica. The experiment was executed with the purpose of testing the following null hypothesis:

When the term ‘pair programming’ was not yet widespread, Nosek investigated Collaborative Programming [15]. Collaborative Programming means ‘two programmers working jointly on the same algorithm and code’. Basically, it was a form of pair programming ante litteram. Nosek executed an experiment with experienced programmers in order to evaluate the impact of collaborative programming on two quality factors: the readability of the code produced by pairs, and the functionality of the solution with respect to the objectives stated in the problem description. The experiment showed that collaborative programmers outperformed the individual programmers. Interestingly, a secondary observations stemmed from the experiment: collaborative programmers reported higher values of enjoyment of the process and confidence about their work. With the growing interest for pair programming in the software engineering research community, more focalized investigations have been published. However, initially the attention of researchers has focussed mainly on quality and productivity, as in [13], [16], [18].

Ho: the difference in education between the pair’s components does not affect the building of system knowledge. The alternative hypothesis is: H1: the difference in education between the pair’s components affects the building of system knowledge. Subjects. The experiment was executed with students of the Master of Technologies of Software (MUTS) and Master of Management and Technologies of Software (MUTEGS), high education university courses for post-graduates, at University of Sannio (http://www.ing.unisannio.it/master/). Students of MUTS own a scientific graduation (engineering, mathematics, physics), whereas students of MUTEGS own an economic/humanistic graduation (economics, philology, literature, philosophy). Both the courses provide the same basic education in computer engineering (operating systems, programming languages, network, database, and software engineering), but MUTS

1479



students are specialised for developing and maintaining Software Systems, whereas MUTEGS students are trained for dealing with the economic and organizational issues of software lifecycle. The two Master courses are held contemporarily with the same professors, in the same campus and both last one year, during which the students follow theoretical classes and lab sessions, develop a large and complex project in connection with an enterprise, participate to seminaries from international experts, perform a three month stage in software companies.

each subject answered an entry questionnaire, individually, for about 15 minutes. The entry questionnaire was aimed at establishing the baseline, i.e. level of knowledge of the system before working on it;  the pairs and the solo designers performed the maintenance tasks for 2 hours;  each subject answered an exit questionnaire individually, in order to understand the knowledge built by practicing the maintenance in the two different ways, pair and solo. Questionnaires. We prepared two questionnaires, QA and QB, in order to measure the dependent variable. Both the questionnaires were distributed as entry and exit questionnaire, so that each subject had randomly QA (or QB) at entry and, conversely, QB (or QA) at exit. This avoided that the results depended on the questionnaire itself. The questions concerned architectural and functional aspects of the system. Although we would have liked to use a CASE tool, such as Rational Rose, or ArgoUML, we finally decided to use only pen and paper. The reason was that some subjects could be more familiar with this kind of tools and this could inject bias in the results. As consequence, we would have needed more time for preparation in order to equalize the ability of subjects to work with tools. We analyze only the exit questionnaire for evaluating the knowledge built. The entry ones helped only to assess the average level of system knowledge. In Table 1 the experimental design is provided, and in Table 2 the outcome of statistical tests are reported.

The subjects were organized as follows: 

4 pairs with one MUTS student and one MUTEGS student;



5 pairs with two MUTS students;



5 pairs with two MUTEGS students;



the other 16 subjects, MUTS and MUTEGS, worked as solo designers.

All the groups were formed randomly. Variables. System’s knowledge represented the dependent variable and it was evaluated by grading a questionnaire, answered by subjects after having performed the maintenance tasks on the system. The questionnaires were evaluated in this way: each correct answer was evaluated 1; each incorrect answer was evaluated 0. The independent variables were the kinds of pairs by classes of subject’s graduation: scientific with scientific, non-scientific with non-scientific, and scientific with nonscientific. Rationale for the sampling from the population. Students of Software Engineering course are suitable for such an experiment because they study software architecture and software system design. Furthermore they usually are employed as software architects or designers after the graduation. MUTS and MUTEGS students are a fine population’s sample, considered that they experienced an actual project work during the overall master. Since the students have comparable curricula, there is not a relevant bias in the sample.

Table 1 . Experimental Design Treatment

Input

4 MUTS

Paired MUTS MUTEGS

Requirement Specification;

4 MUTEGS

Paired MUTEGS MUTEGS

5 MUTEGS 5 MUTEGS 5 MUTS

Paired MUTS MUTS

5 MUTS

Assignment. In order to evaluate the knowledge built by doing while working on the system, the assignment for the subjects consisted of improving the design of the system. The design of the system was formalized in UML and included: textual specification of the system’s requirements, two use cases diagrams, and two class diagrams (for a total of 15 classes). The design was developed by experimenters. Considered the time available, we preferred to avoid bulky documentation.

8 MUTS

Solo

8 MUTEGS

Solo

Output

Use Diagram;

Modifications to Use Case case Diagram and Class Diagram;

Class Diagram; Entry questionnaire QA (or QB); Exit questionnaire QB(or QA).

Answered entry questionnaire QA (or QB); Answered exit questionnaire QB(or QA).

Table 2. Outcome of the first experiment

The maintenance tasks were basically two:  reduce complexity, by erasing entities or relationships between entities not fundamental for understanding; 

Subjects

Tests

Rank Sum (a)

Rank Sum (b)

plevel

p-level 1 tail

MUTS-MUTS (a)

121,00

50,00

0,020

0,020

135,00

75,00

0,023

-

135,00

75,00

0,020

0,023

54,50

116,50

0,049

0,054

57,50

78,50

0,270

0,278

406,00

0,161

0,179

MUTS-MUTEGS (b) MUTS-MUTS (a) MUTEGS-MUTEGS (b)

improve readability, by changing existing entities (use cases, actors, classes, methods), or adding new ones.

MUTS-MUTEGS (a) MUTEGS-MUTEGS (b)

This kind of assignment was targeted at maximizing the knowledge built by doing; as matter of fact, maintenance needs the programmer to analyze in depth the system. The system design was realized by taking into account the knowledge of subjects, with the aim of making objects representative of the population. The Process. The process of the experimental run was the following:  each subject studied documentation for 30 minutes, individually;

MUTS(a) MUTS-MUTS (b) MUTEGS (a) MUTEGS-MUTEGS (b) Questionnaire Questionnaire B

A

- 540,00

The following conclusions have been drawn: forming pairs with individuals with the same educational background (either

1480

scientific with scientific or non scientific with non scientific)emphasizes the expected benefits of pair designing. Coupling a person with a scientific background and one with a non-scientific background does not seem to improve the performance of the latter but to make worst the former.

4. THE DESIGN

REPLICA:

− The null hypothesis cannot be rejected only when comparing Spanish pairs and Italian pairs formed by MUTS students. − The difference between the results of the questionnaires is not significant, thus they do not affect the outcomes of the experiment. Recall that the Spanish education background is comparable with that of the Italian MUTS students.

EXPERIMENTAL

Table 4. Statistical tests

This section discusses the replica. The replica varied the experimental subjects, according to the classification in [1] and was executed testing the same null hypothesis of the first experiment.

Pairs under comparison

MUTS-MUTS(a)Spain(b)

64 students

32 students

Paired

Solo

Input

Output

Requirement Specification;

Modifications to Use Case Diagram and Class Diagram;

Use case Diagram;

p-level

2*1 sided exact p

349,50

1480,50

0,3638

0,3830

148,50

1645,50

0,01413

0,0152

126,00

1585,00

0,0105

0,0115

598,00

677,00

0,2068

-

Italy MUTS MUTEGS (a)Spain (b) Italy MUTEGS MUTEGS (a)Spain (b) Questionnaire QA (a)

Table 3. Experimental design of replica Treatment

Rank Sum (b)

Italy

Subjects. The subjects were students enrolled at the Department of Computer Science at the University of Castilla-La Mancha in Spain. The first group was composed of 42 students enrolled in the final-year (third) of the Computer Science (BSc) in the specialization of Management; the second group was composed of 39 students enrolled in the final-year (third) of the Computer Science (BSc) in the specialization of System; and finally the third group consisted of 12 students enrolled in the final-year of the fifth year of MSc. The curriculum of the Spanish students and that of the MUTS students show many subjects in common; thus Spanish students can be assimilated to the MUTS students. The replica had a different experimental design with respect to the previous experiment: 32 randomized pairs where formed and 32 subjects were left working as solo designers. Subjects

Rank Sum (a)

Questionnaire QB (b)

The second and the third row confirm the findings of the experiment run in Italy: the background of pair’ s components affects the knowledge built. Precisely, the closer the curriculum of both the designers is to scientific profile (like MUTS and Spanish students) the greater knowledge the designers build. The data in the first row reinforces this conclusion: as matter of fact, by comparing two groups of pairs, both formed by designers with scientific background, the difference in results is not statistically significant. Table 5 shows the descriptive statistics of data samples.

Answered entry Class Diagram; questionnaire QA Entry questionnaire (or QB); QA (or QB); exit Exit questionnaire Answered questionnaire QB(or QA). QB(or QA).

Dependent and independent variable, the process, the assignment and the questionnaires remained the same but: the overall process in Spain lasted 2 hours and the experimental object was properly translated in Spanish by the native Spanish language speaking authors.

Pairs

5. DISCUSSION OF RESULTS

MUTS

Table 5. Descriptive Statistics of Data

Italian MUTS

Std Dev.

Average Moda

Max Min

1,75

5,8

4

9

4

In Table 4 the results of statistical tests are reported. We used Mann Whitney test because the data of samples did not show normal distribution and fixed the p-level at 0.05.

Italian MUTS MUTEGS

1,60

3,9

3

7

1

From the statistical tests the following outcomes can be derived:

Italian MUTEGSM UTEGS

0,76

4

4

5

3

Spanish

1,31

5,1

5

7

1

− The null hypothesis can be rejected in two cases: when comparing the Spanish pairs and Italian pairs formed by MUTS and MUTEGS students; and when comparing the Spanish pairs and Italian pairs formed by MUTEGS students.

1481

Precisely, the best results are obtained when the background is scientific.We have detected some limitations in our experiment, to be overcome with future replicas.

Standard Deviation

The first limitation stands mainly in the experimental objects. The subjects used as the modeling language UML and design techniques traditionally thought in BSc courses. It should be interesting to evaluate learning of junior designers while faced with concerns of real world projects, including quality procedures, special architectural styles, and frameworks for complex systems, such as distributed, mobile, and services-based applications. The second limitation is the questionnaire as a means to capture the tacit knowledge level and, thus, the knowledge building. Tacit knowledge for its intrinsic nature is hard to capture completely, and it cannot be formalized. Evaluating it by using questionnaires about the design of the system and design technique is an acceptable approximation. More sophisticated instruments could be more effective, but in this case the experimentation has to become multidisciplinary; it should include psychology research, at least. The third limitation regards the construct. For sake of precision we must point out that the experiment focuses on student learning, rather than on comprehension-in-practice. With comprehension in practice we mean the knowledge that practitioners build by performing their daily work. Both are forms of tacit knowledge building, and both are intended to occur when people, either students or practitioners, perform development activities. However, at a finer analysis, differences can be identified. Students are committed in learning and whenever they work during classes or labs, also during the experiment, their efforts are headed in this direction. Practitioners do not necessarily concentrate their efforts in learning during their daily work. Comprehension in practice is a kind of unconscious learning and it occurs spontaneously when people face new problems. In this case, practitioners convey their efforts just on work: learning comes as a side-effect. Finally, in both the cases we can observe how knowledge is built by doing, but we must consider that a difference exists. The aim of students is to apprehend: the learning is the primary goal; on the contrary, the only aim of practitioners is realizing successfully their tasks: the learning, when occurs, is not a primary and voluntarily pursued goal. These three limitations should be mitigated by considering the context of the experiment, that is student learning: this saves the consistence of the overall experimental structure, considering that the limitations are part of the experimental ‘vitro’.

2 1,5 1 0,5 0 Italian MUTSMUTS

Italian MUTSMUTEGS

Italian MUTEGSMUTEGS

Spanish pairs

Figure 1. Graph of Standard Deviation The highest standard deviation is reported by Italian MUTSMUTS pairs, although the value of Spanish pairs is enough great. As matter of fact, the minimum value of the sample is about 86% the maximum value, as Table 5 shows. This suggests that the practice of working in pairs emphasizes individual capabilities when merging together designers with scientific background.

Media

Average 7 6 5 4 3 2 1 0 Italian MUTSMUTS

Italian MUTSMUTEGS


Spanish pairs

Figure 2. Graph of Average Values The graph for the values of the average (Figure 2 ) confirms that pairs formed by scientific components (Italian MUTS-MUTS and Spanish pairs) built a greater knowledge, comparing with the other kinds of pairs, whose components have different background.Figure 3 shows the more frequent values (Moda) in the groups. The highest values are reported by pairs whose both the components own scientific background. Once more the background is determinant in increasing the knowledge built by practice.

5.1 Validity Threats

Moda

Four major validity threats are discussed in the following.

6

Random heterogeneity of subjects. Subjects come from three different undergraduate courses. This threat is minimal, because all of them owned the necessary knowledge to perform the tasks.

5 4 3

Mono-operation bias. We used one system design documentation as the only experimental object. Actually, we blocked this factor, that is the system the practice is applied to.

2 1 0 Italian MUTSMUTS

Italian MUTSMUTEGS


Evaluation apprehension. Questionnaires were not anonymous; this is an unavoidable threat, because professors were interested in knowing the students taking part to the experiment. Moreover, the students were volunteer.

Spanish pairs

Figure 3. Graph of Moda Values

1482

Interaction of setting and treatment. The setting and the material were partial representative of real world. The design system was trivial in size, if compared with real system whose architecture is more complicated. But it should be considered part of the experimental environment: the subjects were students instead of practitioners.

[2] Beck, K., Extreme Programming Explained: embrace change. Addison-Wesley, Reading, Massachusetts, 2000. [3] Brooks,P., The Mythical Man Month: Addison Wesley Publishing Company, 1995. [4] Canfora, G., Cimitile, A., and Visaggio, C. , A. , Working in pairs as a means for design knowledge building: an empirical study. In Proceedings of IEEE International Workshop on Program Comprehension, 2004. [5] Canfora, G., Cimitile, A., and Visaggio, C.,A., Lessons learned about Distributed Pair programming: what are the knowledge needs to address? In Proceedings of Knowledge Management of Distributed Agile Process-WETICE, IEEE Computer Society, 2003. [6] Carver, J., Jaccheri, L., Morasca, S., and Shull, F., Using Empirical Studies during Software Courses. Experimental Software Engineering Research Network 2001-2003. LNCS 2765, 2003. [7] Cockburn, A., Characterizing People as Non-Linear, FirstOrder Components in Software Development. In Proceedings of 4th International Multi-Conference on Systems, Cybernetics and Informatics, Orlando, 2000. [8] Foresythe, G., B. , Hedlund, J., Snook, S., Horvath, J., A., Williams, W.M., Bullis, R.C., Dennis, M. and Sternberg, R., Construct validation of tacit Knowledge for military Leadership, Annual Meeting of the American Education Research Association, 1998. [9] Höst, M., Regnell, B., and Wholin, C., Using Students as Subjects – A comparative Study of Students & Professionals in Lead-Time Impact Assessment. In Proceedings of 4th Conference on Empirical Assessment & Evaluation in Software Engineering (EASE), 2000. [10] Kitchenham, B., Pfleeger, S., Pickard, L., Jones, P., Hoaglin, D., El Emam, K., and Rosenberg, J., Preliminary Guidelines for Empirical Research in Software Engineering. IEEE Transactions on Software Engineering, 28 (8), 2002. [11] McDowell, C., Werner, L., Bullock, H., and Fernald, J., The Effects of Pair Programming on Performance in an introductory Programming Course, In Proceedings of the 33rd Technical Symposium on Computer Science Education, ACM, 2002. [12] Melnik, G. and Maurer, F., Direct Verbal Communication as a Catalyst of Agile Knowledge Sharing. In Proceedings of the Agile Development Conference 2004, IEEE Computer Society. [13] Nawrocki, J. and Wojciechowski, A. Experimental Evaluation of Pair Programming. In Proceedings of European Software Control and Metrics, 2001. [14] VanDerGrift, T., Coupling Pair Programming and Writing: Learning About Students’ Perceptions and Processes. In Proceedings of SIGCSE, ACM, 2004. [15] Williams, L., and Kessler, B., The Effects of "Pair-Pressure" and "Pair-Learning". In Proceedings of 13th Conference on Software Engineering Education and Training , IEEE Computer Society ,2000 . [16] Williams, L., Cunningham, W., Jeffries, R., and Kessler, R. R. Straightening the case for pair programming. IEEE Software, 17(4), IEEE Computer Society, 2000. [17] Williams, L., and UpChurch, R., L., In Support of Student Pair-Programming. In Proceedings of the thirty-second SIGCSE technical symposium on Computer Science Education, ACM, 2001.

6. CONCLUSIONS A growing interest in the software engineering community is turning toward agile practices, such as pair programming. More precisely, a lack of experimental validation of supposed benefits constitutes one of the main concern. Pair programming is expected to foster knowledge leveraging between pair’s components. We have applied pair programming to the design phase, naming it pair designing. We have conducted an experiment at University of Sannio, Italy and a replica at University of Castilla-La-Mancha, Spain in order to confirm the findings of the first experiment. This could help for using pair programming as a means for quickly training people and assimilating them in projects. We found confirmations that forming pairs with individuals with the same educational background emphasizes the expected benefits of pair designing. Coupling a person with a scientific background and one with a non-scientific background does not seem to improve the latter but to make worst the former. This finding could be very useful in universities daily practice. In fact, in Europe due to the recent European agreements, university education is experiencing a turn from a teaching style to a learning style, in which students must learn by themselves with the guidance on teachers. When planning this kind of education it would be very interesting –in scientific subjects- to consider pair building in order to increase learning. The experiment owns an (apparent) point of weakness: it is not executed in industrial setting. Students play a very important role in the experimentation in software engineering, as pointed out in [1], [10]. In situations in which the tasks to perform do not require industrial experience the experimentation with students is viable [9], [1]. The experiment owns also a point of strength: the number of subjects is approximately 100, and it seems to us discretely valuable for statistical dependability. As future work, we would like to include psychology research, at least in two directions: a more appropriate tools for knowledge capturing and controlling other psychological factors such as personality . .

7. ACKNOWLEDGEMENTS We’d like to thank Crescencio Bravo and Manuel Serrano for their help in executing the experiment. This research is supported by the MAS project partially supported by “Dirección General de Investigatión of the Ministerio de Ciencia y Tecnología” (TIC 2003-02737-C02-02).

8. REFERENCES [1] Basili, V., Shull, F., and Lanubile, F., Building Knowledge Through Families of Experiments. IEEE Transactions on Software Engineering, 25, 4, 1999, 456-473.

1483

[18] Williams, L. ,A. , The Collaborative Software Process, PhD Dissertation, in Department of Computer Science. Salt Lake City, UT: University of Utah, 2000. [19] Williams, L., Shukla, A., and Anton, A.,I. An initial Exploration of the relationship between Pair programming and Brook'’ law. In Proceedings of the Agile Development Conference 2004, IEEE Computer Society.

1.Could Remote Registration of User (User Remote Registration Sending) extend local user registration (User registration Sending)? a. Yes

b. No and it does c. Possible, with not make sense proper modifications

2. Does the updating of user data (User Remote Registered Updating) require the correctness and completeness check (Correctness/Completeness Checker)? a. Yes


3. Could use cases Notification of Transaction To Buyer and Notification of Transaction To Branch be merged in one use case?

Send User Registration

a. Yes

HeadQuarterSyste m Brench Operator

4. Could the use case Update Database extends the use case Local Book Search?

Send Brench Regist rat ion

a. Yes

Check Correctness/Completeness


5.Given a transaction, can information concerning vendor be obtained through the Book (object)?

Checking Tesaurus

a. Yes Update User Remot e Registred



6. A (object) Branch Operator must have executed at least one operation, otherwise it does not exist in the System. Send User Remote Registration

User

Brenc hSystem

a. True

9. APPENDIX

b. False

c. This information is not provided by documentation.

7. It is possible to obtain the list of registered users in a local branch through Data contained in a Branch (object).

Figure 4. An exemplar Use Case 1.1.1 Use Case

Send User Registration

a. True

1.1.1.1.1 Description

The Branch operator inserts data in the registration form, provided by the user. Validation of the form is launched.

8. DataHandler (object) helps query the Database.

The form is not correct or complete.

a. True

Exceptions

b. False

b. False

The sending of data is successfulness.

c. This information is not provided by documentation. c. This information is not provided by documentation.

Actors

BrenchOperator, HeadQuarterSystem.

9. Checker (object) verifies if all the fields of the form are filled in.

Use Case Extends

Nn

a. True

Use Case Uses


Use Case Inputs

Name, address, offered books list (in case the user is a vendor) with specifications: title, author, publisher, language, publishing year, ISBN.

Use Case Outputs

Recording of data of the new user.

Criterion of Acceptance

Data of the new user are stored in the database of the Local Branch.

Related Expectations

Database management system.


10. The user interface is provided only for the remote part of the system. a. True

b. False


Figure 6. Questionnaire QB

Correctness and completeness checks. Data sending to the Headquarter. Related Reqs/ Use Cases

b. False


Figure 5. Excerpt of Use Case specification

1484