apply cooperation active problem solving methods, namely think-pair-square [8].
In this work, we have modified the original definition of the think-pair-square.
A New Method for Cooperatively Modeling Use Case Diagrams in the Context of Global Software Development Ugo Erra and Giuseppe Scanniello
Abstract In this paper, we propose a new cooperative problem solving method for the modeling of high level use case diagrams in the context of global software development. This method has been implemented in an integrated environment for the synchronous communication and modeling and two controlled experiments have been conducted to compare the developed technology (i.e., the method and the supporting environment) with a brainstorming session based on face-to-face interaction. The data analysis indicates a significant difference in favor of the brainstorming session for the time, with no significant impact on the quality of the use case diagrams.
1 Introduction Splitting the development of a software product (e.g., system or service) among globally distributed sites is increasingly becoming a common practice in the software industry [7]. Academy and industry community refers to this relevant phenomenon as global, distributed, or multi-site software development [10]. Some of the challenges related to the development in geographically distributed settings are due to the fact that the greater part of the available approaches and methods try to apply well established and consolidated practices of the traditional software engineering field. Both in traditional and global software development contexts, requirements engineering aims at defining the features that the system must have (i.e., functional requirements) or constraints (i.e., quality or pseudo requirements) that it must satisfy to be accepted by customers. The most challenging phase of the requirements Ugo Erra Universit`a della Basilicata, Dipartimento di Matematica e Informatica, e-mail:
[email protected] Giuseppe Scanniello (corresponding author) Universit`a della Basilicata, Dipartimento
[email protected]
di
Matematica
e
Informatica,
e-mail:
1
2
Ugo Erra and Giuseppe Scanniello
engineering is the requirements elicitation [2] since it is mainly concerned with communication, cooperation, and problem-solving tasks. Hence, it seems reasonable to apply cooperation active problem solving methods, namely think-pair-square [8]. In this work, we have modified the original definition of the think-pair-square method to make it suitable for the global software development and for the specification of functional requirements in terms of high level use case diagrams, in particular. A prototype of a supporting tool is also proposed here. To make the developed technology (i.e., the proposed method and the supporting tool) attractive in academy and industry community two controlled experiments have been conducted and the results have been shortly presented in the paper.
2 The Proposed Method We propose a new method for global software development with application to the requirements elicitation. Our proposal is based on the well known and widely used think-pair-square method [8]. The think-pair-square method is conceived for promoting active learning to solve problems in cooperative fashion. This method gives individuals the opportunity to discuss their ideas or possible solutions for a given problem and provides means to observe problem solving strategies of the others. Individuals are grouped in homogeneous or heterogeneous way and are asked to solve problems through the following sequential three steps or phases: think is individually accomplished to approach a solution for a problem. The prompt should be limited so that each individual can really focus on the start point. This allows for wait time and helps individuals control the urge to impulsively shout out the first answer that comes to mind. pair is performed in pair, who share the possible solutions individually identified in the think step. In this step individuals may wish to revise or alter their original ideas. square is performed by all the individuals together, who work on the common solution of the problem. Individuals share the work made in the pair phase by the two or more pairs, thus forming a square and discussing again possible solutions for the original problem. This should allow individuals to identify a shared and more comprehensive solution. Individuals perform the pair and square phases in the same physical setting through face-to-face interaction. The rationale for performing these steps relies on the fact that if one pair of individuals is unable to solve the problem, the other pair can often explain their answer and strategy. Finally, the pairs combine their results and generate a more comprehensive solution.
A New Method for Cooperatively Modeling Use Case Diagrams in the Context
3
2.1 Distributed Think-Pair-Square and Supporting Tool Requirements engineering aims at defining the features (i.e., functional requirements) that a system must have or constraints (i.e., quality or pseudo requirements) that it must satisfy to be accepted by the customer. The most challenging and demanding phase of the requirements engineering process is the elicitation [2]. Requirement elicitation is a non-trivial task because you can never be sure you get all requirements from the user and customer by just asking them what the system should do. This phase is concerned with several activities. Among these activities communication, cooperation, requirements modeling, and problem-solving are the most demanding and these become even more difficult in case software engineers are geographically distributed. Based on [5] and on the fact that the think-pair-square method is used to promote active discussions and to solve problems, it seemed reasonable to adapt it to support distributed requirements elicitation. Indeed, we propose here a variation of the original definition of the think-pair-square method to model software requirements in cooperative and distributed fashion. With respect to the original definition of the method, we have replaced the face-to-face interaction with computer-supported collaboration tools. In particular, the face-to-face interaction has been replaced with a distributed communication/modeling environment composed of a text-based chat and a synchronous use case diagram modeling tool. The chat is in charge of simulating the face-to-face interaction, while the modeling environment is to take note of the possible software requirements models (identified at each step) abstracted by using high level use case diagrams. The latter tool also enables implicit communication1 [6] while performing modeling tasks. Some variants of think-pair-square are available to facilitate class discussions and solve problems in cooperative fashion: think-pair-share and think-pair-squareshare. We based our proposal on think-pair-square because the share2 step makes the two variants not suitable for modeling tasks. In fact, it is not vital for the success of a software project to share all the possible alternatives for software models. This could introduce useless overhead and delay the software development. Differently, the share step could be more appropriate in software engineering tasks where all the possible solutions of an issue have to be shared among team members, such as the rationale management [4]. A prototype of a communication/discussion environment has been implemented using CoFFEE [3]. Although CoFFEE is mainly aimed at improving cooperative learning in the context of computer support work-groups, it also offers tools to support distributed synchronous cooperative activities during discussions. It provides three main tools: (i) Session Editor, (ii) Controller, and (iii) Discusser. In the following, we provide details on how we used these tools for developing our commu1
It is a knowledge transfer process based on communication through a shared mental or abstract model. 2 Individuals are called upon to share with the rest of the class possible solutions of the problem to provide closure to the discussion.
4
Ugo Erra and Giuseppe Scanniello
nication/discussion environment. Session Editor The Session Editor tool is used to define a communication/discussion environment by means of a session that is in turns composed of steps. The activities that can be accomplished within each step are defined combining one or more basic tools. We used: the Chat Tool (CT) and the Shared Drawing Tool (SDT). CT is a traditional synchronous text-based chat, while SDT is a synchronous environment for modeling diagrams [9] (the UML use case and class diagrams are currently supported). We have created a communication/modeling environment, whose underlying session is composed of three steps (one for each phase of the method) using the CoFFEE Session Editor (see the tab Session Details of Figure 1). In all the defined steps, SDT is provided to specify the high level use case diagram of a given software system. Differently, CT is included in the second and third steps to enable the communication and to support the discussion. CT is employed to enable the communication among team members, while SDT was for presenting a graphical overview of the functionality provided by a system in terms of actors, use cases, and dependencies between use cases and actors. Figure 1 shows in the tab Step Details the tools used in the Pair step. The CoFFEE Session Editor also provides a Layout preview (see on the bottom right hand side of Figure 1) to highlight how the tools will be show. To effectively support our method, at each step the model created by using SDT is made available to the subsequent one.
Fig. 1 The Session Editor.
A New Method for Cooperatively Modeling Use Case Diagrams in the Context
5
Fig. 2 The Controller.
Controller The Controller tool enables to execute the session. The first step that a coordinator has to accomplish concerns the composition of groups and then he/she has to start the session . The coordinator can also constantly monitor the interactions among the team members within communication/discussion environment. The session behind our method and how it is shown within the Controller tool is depicted in Figure 2. On the top left hand side of this figure, it is shown the tab Control Panel that enables the coordinator to associate each individual (e.g., RUSSO) to a team (e.g., 1) within the Think step (see on the middle of the tab SessionControl). In this case, each individual is assigned to a different group since the Think step has to be individually accomplished. The team composition has to be performed also for the subsequent steps of the method. For the Pair step, the teams will be composed of two individuals, while a team of four will be formed in the last step. Once the composition of the teams for each step is accomplished, the session is executed pressing the button on the top of the tab SessionControl. The experimenters managed the Controller tool in the experiments to start the modeling tasks, to pass from a step to another, and to compose the teams in the Pair and Square steps. Discusser The Discusser tool allows using the environment created by the Session Editor tool and executed by the Controller tool. In particular, the communication among team members follows the session underlying the communication environment and is supported by the tools that compose this session. Figure 3 and Figure 4 show the integrated communication/modeling environment implementing our method with respect to the Think and Square steps, respectively. Regarding the Think step, the discusser only provides features to compose a use case diagram (i.e., the SDT tool). Differently, the environment provides both the tool CT and SDT in the Pair and Square steps. The diagram produced in the previous
6
Ugo Erra and Giuseppe Scanniello
accomplished step is made available (see on the left hand side) in the SDT tool. In the Square step the CT messages of the Pair step can be also visualized. The access to both the use case diagrams and the chat messages is possible by using the tabs on the top of the environment (see Figure 4).
Fig. 3 The Discusser tool.
Fig. 4 The Discusser tool for the Square step
A New Method for Cooperatively Modeling Use Case Diagrams in the Context
7
3 The Experiments In this section, we highlight the conducted experiments and the achieved results. A technical report, the experimental package, and the raw data are available for downloading on the web3 . Design The experiments aimed at investigating whether our method and its implementation are effective as a traditional brainstorming session in the modeling of functional requirements abstracted by high level use case diagrams. The goal of our experimentation can be therefore defined by using the GQM (Goal Question Metric) [1] template: “Analyze the use of our technology for the purpose of comparing it with respect brainstorming session based on face-to-face interaction from the point of view of the researcher, evaluating the possibility of adopting the technology in the modeling of high level use case diagram in the context of students in Computer Science, and from the point of view of the project manager, evaluating the possibility of adopting the technology to model high level use case diagram in the context of a global software development project”. The context of the experiments was constituted of Bachelor and Master students in Computer Science at the University of Basilicata. All the students were volunteers and were aware of the pedagogical purpose of the experiments, but they did not known the experimental hypotheses. The experiments were performed in a controlled laboratory. The adopted design ensured that each team worked on two different experimental objects. The objects were different in the two experiments. All the experimental objects were similar in complexity and refer to application domains on which the participants were sufficiently familiar with. In each experiment the participants were asked to accomplish 2 tasks. For each task, the participants were asked to create a high level use case diagram using and exploiting either our technology or a brain storming session. We equally distributed high and low ability participants among the teams and each team contained 3 Bachelor students and 1 Master student. To compare our method and its implementation with a brainstorming session, we studies: (i) the time (in minutes) that all the participants of a team spent to model a high level use case diagram; and (ii) the quality of the produced models. Results The data analysis indicates (as it was easy to imagine) that the participants grouped in teams significantly spent less time to accomplish a modeling task when using a traditional brainstorming session. Differently, the participants produced on average better quality models when accomplished the task using our method and tool. Their effect is not statistically significant. The results may have practical implications: in case the time distance is not an issue, but moving people might be a problem, our proposal represents a viable alternative to brainstorming sessions for the modeling of high level use case diagrams.
3
www.scienzemfn.unisa.it/scanniello/TPS UCDiagrams/
8
Ugo Erra and Giuseppe Scanniello
4 Conclusions and Future Work We have proposed a novel method for the specification of functional requirements in distributed global software development. A prototype of a supporting environment has been implemented as well. A remarkable characteristic of this prototype is that it is simple to set up, to maintain, and to extend as compared to the widely employed communication media (e.g., videoconferencing communication tools) and modeling tools traditionally used in the global requirements engineering field.
References 1. V. Basili, G. Caldiera, and D. H. Rombach. The Goal Question Metric Paradigm, Encyclopedia of Software Engineering. John Wiley and Sons, 1994. 2. B. Bruegge and A. H. Dutoit. Object-Oriented Software Engineering: Using UML, Patterns and Java, Second Edition. Prentice Hall, 2003. 3. R. De Chiara, A. Di Matteo, I. Manno, and Scarano V. Coffee : Cooperative face2face educational environment. In CollaborateCom, pages 243–252, 2007. 4. Allen Dutoit, Raymond McCall, Ivan Mistr´ık, and Barbara Paech. Rationale Management in Software Engineering. 2006. 5. U. Erra, A. Portnova, and G. Scanniello. Comparing two communication media in use case modeling: Results from a controlled experiment. In IEEE Int’l Symp. on Empirical Software Engineering and Measurement (ESEM 2010), September 2010. 6. A. Gupta. 24-hour knowledge factory paradigm and its role in surmounting organizational, national, and other barriers. 2009. 7. J. D. Herbsleb and A. Mockus. An empirical study of speed and communication in globally distributed software development. IEEE Trans. Software Eng., 29(6):481–494, 2003. 8. F. T. Lyman. The responsive classroom discussion: The inclusion of all students. In In A. Anderson (Ed.), Mainstreaming digest, pages 109–113. College Park, MD: University of Maryland Press, 1981. 9. OMG. Unified modeling language (UML) specification, version 2.0. Technical report, Object Management Group, July 2005. 10. B. Sengupta, S. Chandra, and V. Sinha. A research agenda for distributed software development. In Proceedings of the 28th international conference on Software engineering, pages 731–740, New York, NY, USA, 2006. ACM.
