The work-reflection-learning cycle - Department of Computer and ...

More documents

Recommendations

Info

member. Field notes were made during and immediately after the sessions, to the extent possible. The team’s supervisor was interviewed during and after the project, and the team’s customer was interviewed after the project. The team was interviewed once during the middle of the project and once after completion of the project. Most of the meeting recordings and interviews have been fully transcribed. Recordings from work sessions have been partly examined and summarized based on their perceived relevance in the analysis process. Quotations have been translated into English by the researcher at need. Analysis of the data started out with some theoretical concepts being perceived as central (cf. the Principle of Abstraction and Generalization, [24]). Coding was performed on the basis of these concepts, by the aid of a computerized qualitative analysis tool (Atlas.ti). New codes were added as themes developed during interpretation and writing. For instance, PLENTI was used as a code to mark and organize data related to the team’s use of the framework and interaction with the community. Further, the data have been chronologically structured within selected themes. The researcher was the coordinator of the project course, grading the projects, but not supervising any group. In the process of observing the Anniva team, great care was taken to avoid mixing up the roles of researcher and course staff and to be aware of the possible effects of ‘the teacher being present’ (cf. the Principle of Interaction Between the Researcher and the Subjects, [24]). As part of the initial agreement between the researcher and the team, it was decided that another member of course staff set the grade on their project. Further, it was agreed that the researcher was not to supervise them, but restrain interaction to being social without causing too much disturbance. The reason for not supervising was not mainly that supervision would influence the case. The influence of the researcher is an inevitable consequence of participant observation, even if the degree of influence can, and should, be limited. The team was not, however, to be given advantages as compared to the other teams in the course, or at least the sum of advantages and disadvantages of being research subjects should be perceived as close to zero by the team and by the other teams. These considerations impacted on the possibility to have the researcher’s interpretation validated with the research subjects during the study (cf. the Principle of Multiple Interpretations, [24]). As all teams in the course were however interviewed about their project work and viewpoints on the course in the middle of the semester, and on that occasion it was possible to have some prompted viewpoints from the Anniva team. Also, the day after the completion of the project, a three hour interview was conducted with the team to have their feedback on the researcher’s preliminary interpretation of the project. In reflective discussions within the team towards the end of the project and in the interview conducted after the project, the team expressed that they had perceived the researcher as non-interfering and agreeable, and that they had not received project supervision from her. To validate findings reported in this paper, a draft version has been reviewed by two of the team members, Owen and Ethan. Ethan expressed that he liked the paper. Owen provided more detailed viewpoints which have been incorporated in the Analysis and Findings and Discussion sections. 5. ANALYSIS AND FINDINGS In presenting the findings of our study in terms of the team’s interaction with the PLENTI community, we have made a chronological structuring of the material, distinguishing what we see as four partly overlapping phases. The first phase is a (dis)orientation phase in which the team strives to understand what PLENTI is and how to obtain adequate knowledge about the framework. In the second phase, PLENTI is regarded by the team as an obstacle, but starts taking on the role of a tool (albeit not quite mastered by the team). In the third phase, the team is communicating with PLENTI users and developers through the listserv of the community, actively making use of the framework as a tool in the project development task. In the fourth phase signs of a feeling of identity related to the PLENTI community participation can be found in the team, and the team is contributing to the PLENTI development. In the subsequent discussion (Section 6), we will argue that the transition to the third phase was essential to the project, and address how this transition came about in our case. In the present section, we characterize each phase in more detail, giving some illustrative excerpts from the data where appropriate. 5.1.1 First phase (January-February): What is PLENTI? In the original project description as well as in the initial customer meeting, it was specified by the customer that PLENTI should be used as a development framework. The reason was that one of the two customer representatives had attended a seminar with an enthusiastic PLENTI developer and thus caught interest in the framework. During the first customer meeting, the team was offered the alternative of using another framework, but not PHP, which was the only alternative with which they were familiar. This left PLENTI as the de facto option. Adding to the arguments to use PLENTI, the customer expressed interest in having it tried out to see how it worked for this type of application development. None of the students in the team had any advance knowledge about PLENTI. Further, no one had any experience with the programming of web applications with servlets. The web pages of the PLENTI community were the only resource about the framework known to the team. The team decided that every team member was to learn PLENTI and participate in the programming tasks. Two team members, Sam and Owen, were assigned the task of starting the knowledge acquisition about PLENTI. Ethan and George, accepted as the lead programmers in the team, took on the task of developing a prototype to demonstrate to the customer as a basis for refining the functional requirements. Ethan worked on the web user interface whereas George focused on the underlying business logic, none of them making use of PLENTI for their tasks. Both programmers participated in team-internal discussions on the role and use of PLENTI, though. The fifth team member, Morgan, took the role as project manager, which made him mainly responsible for overall project planning, generating and handing in bi-weekly status reports and activity plans to the supervisor, scheduling meetings, and making sure that work on the project report progressed in accordance with the deadlines. 794 112
5.1.2 Second phase (February-May): PLENTI as an obstacle gradually becoming a tool It soon became evident to the team that getting into the workings of the framework was not an easy task. Sam and Owen spent many hours in the PC lab reading through descriptions and examples, Sam doing some exploratory coding and Owen reflecting overview level information on the framework in the Software Development Plan which had to be handed in early in February. The web documentation of the framework turned out to rely on the reader’s prior knowledge of the development of web applications, which the team lacked. The examples provided in the material were not relevant enough for the team to be able to easily draw on them. The team explained their challenges with PLENTI to the supervisor and the customer in meetings with them. Exhibit 1: Excerpt from February 16, meeting between the team and the customer: Ethan: ”We had a bit of trouble with, with.. that is, we have a small problem with the PLENTI documentation. It is a bit.. They have a lot of examples, but there is sort of nothing that is.. the most basic stuff. They assume that you know quite a lot.” Owen:”The examples and documentation found there are mainly presentations, mostly of how PLENTI is better than earlier and similar tools. We have some problems with, sort of.. the totally basic stuff, they aren’t explained anywhere, so it becomes a lot of trying and failing.” Ethan and George continued focusing on their preferred parts of the prototyping work, and in the larger part of this phase, the team had little progress with their understanding of PLENTI. Gradually some knowledge of the workings of PLENTI developed, however, as the programmers started using the framework in their prototyping. The team was however aware that they did not yet utilize the powerful mechanisms that would be the main reason for using the framework. Attempts to do the latter were postponed, awaiting the completion and demonstrating of the prototypes. Also, work on design and architecture models of the auctioning system was postponed, again with reference to the lack of understanding of how PLENTI should be used. In the eyes of Ethan, it would be more or less meaningless to draw a design model: “It would just be a big box named PLENTI with a number of arrows coming out of it”. In the midterm version of the project report, handed in on March 7, as well as in the related oral presentation, PLENTI was still presented by the team as something they needed to learn properly. The auctioning system prototype demonstrated was mostly a mockup and hardly made use of any of the functionality in the framework. In the customer meeting on March 28, it was clear to the customer as well as to the team that the progress of the project was not satisfactory. Exhibit 2: Excerpt from March 28, meeting between the team and the customer: Ethan: ”Ok, we have made several prototypes, so that.. we have learnt PLENTI by programming. But we haven’t made any completely robust solutions yet.” Owen: ”And then we have used a lot of time to learn, study PLENTI, then, because the documentation is quite bad, I think.” 5.1.3 Third phase (April-May) Gradual PLENTI community participation In the customer meeting on March 28. Ethan reports “having been a bit on the IRC” communicating with the PLENTI community, reporting that there was “this guy” that he communicated with. Exhibit 3: Excerpt from March 28, meeting between the team and the customer. Ethan talks, quoting his IRC communication with Bernhard: ’Why do you do it that way?’ And we just: ‘What? That’s how we do it in JSP.’ ’Don’t do it that way!’ No good, no good, so…” Expressing the above, explaining how Bernhard had reacted negatively to their approach, Ethan still appeared satisfied with the IRQ dialogue. He had in fact reached a PLENTI developer with his request, and the dialogue resulted in relevant directions for the team. After the Easter holiday, following up on the success with IRC, Ethan turned to the PLENTI users forum, a listserv service linked to the PLENTI web pages. The subsequent interaction between Ethan and the community in this forum amounted to eight threads, most of which with several postings, during the course of the project. A condensed thread from the forum is shown in Exhibit 4. Other requests from Ethan were addressed by Bernhard partly in parallel, in different threads. Exhibit 4: Excerpt from April 13.-18., PLENTI users forum on the Internet: April 13.: Ethan: ”We’re trying to make a credentials manager for authenticating against LDAP. We’ve written some code but we’re unsure about what to do next, or if the code is correct. Any ideas? .. Code: ” April 14.: BG “Hi Ethan, using the upcoming PLENTI 1.6, it’s very easy to plug in your own credentials manager ” April 16. Ethan: “Hi, Bernhard, In addition to , what files do we need? ” April 18.: BG: “Just should suffice ” April 18.: Ethan: “Thank you Bernhard! That worked perfectly. We have now functioning LDAP authentication in our webapp. Has integrating LDAP authentication directly in PLENTI been considered? Sincerely, Ethan Lake” April 18.: BG: “Wonderful! Several people have asked for it in the past, it would be a very welcome contribution to the project.” Whereas the communication shown in Exhibit 4 took place in the PLENTI users forum (as opposed to the developer forum, which also could be found on the web site), changes to PLENTI itself were discussed in the last two postings. The initial posting was the first request from Ethan on the forum. Bernhard, the chief developer of PLENTI, was, with one exception, the one who answered Ethan’s (and a number of other users’) requests on the listserv. He gave quick response, often on the same day (or night). These observations together may be taken as an indication that the OSS community is a very small one, with small distance between user and developer as well as between user issues and development issues. At one point, Ethan was asked by Bernhard to send large pieces of code by private email instead of pasting the code directly into the forum. Ethan sent code by email as requested. On a couple of 795 113
Page 1 and 2:
Birgit Rognebakke Krogstie The work
Page 3 and 4:
Figure 1: Most used terms in the th
Page 5 and 6:
Abstract In project based learning,
Page 7 and 8:
Preface This thesis is submitted to
Page 9 and 10:
Acknowledgements I would like to th
Page 11 and 12:
Contents 1 Introduction ...........
Page 13 and 14:
Research paper P4 135 Research pape
Page 15 and 16:
Figure 17: Support for learning in
Page 17:
Abbreviations CSCL CSCW IS NITH NTN
Page 20 and 21:
The work-reflection-learning cycle
Page 22 and 23:
Page 24 and 25:
Page 26 and 27:
Page 28 and 29:
Page 30 and 31:
Page 32 and 33:
Page 34 and 35:
Page 37 and 38:
3 Software Engineering student proj
Page 39 and 40:
Software Engineering student projec
Page 41 and 42:
Page 43 and 44:
Page 45:
Page 48 and 49:
Page 50 and 51:
Page 52 and 53:
Page 55 and 56:
5 Results This chapter presents an
Page 57 and 58:
Results The background of P2 is a l
Page 59 and 60:
Results project management and coll
Page 61 and 62:
Results proposed in P5 was to allow
Page 63 and 64:
Results Analysis of the results sho
Page 65 and 66:
Results archives are found to conta
Page 67 and 68:
Results (SVN). Trac provides lightw
Page 69:
Results Figure 15: A model outlinin
Page 72 and 73:
Page 74 and 75:
Page 76 and 77:
Page 78 and 79:
Page 81 and 82: 7 Evaluation In this chapter, I eva
Page 83 and 84: Evaluation adds to the CSCW literat
Page 85 and 86: Evaluation 7.3 Evaluation of the re
Page 87 and 88: Evaluation In the longitudinal stud
Page 89 and 90: Evaluation According to the princip
Page 91 and 92: Evaluation However, only some of th
Page 93 and 94: Evaluation to design is problematic
Page 95 and 96: 8 Conclusion and further work This
Page 97 and 98: Conclusion and recommendations for
Page 99 and 100: 9 References Abran, A., Moore, J. W
Page 101 and 102: References Cobb, P. (1994). "Where
Page 103 and 104: References Herbsleb, J. D., Mockus,
Page 105 and 106: References Leont'ev, A. N. (1981).
Page 107 and 108: References Stahl, G. (2002). "Build
Page 109 and 110: Glossary B Boundary object - artifa
Page 111 and 112: Glossary maintaining the system aft
Page 113 and 114: Appendix A: Research papers P1 P2 P
Page 115 and 116: Research paper P1 Title: Cross-Comm
Page 117 and 118: Cross-Community Collaboration and L
Page 119 and 120: the course staff may improve the co
Page 121 and 122: 4: Case findings: students’ view
Page 123 and 124: own account of why each artifact is
Page 125 and 126: Research paper P2 Title: Power Thro
Page 127 and 128: Power Through Brokering: Open Sourc
Page 129: Due to the openness of OSS communit
Page 133 and 134: Getting from the second to the thir
Page 135 and 136: 6.2.1 Benefits for SE student proje
Page 137 and 138: Research paper P3 Title: Do’s and
Page 139 and 140: DO‟S AND DON‟TS OF INSTANT MESS
Page 141 and 142: a chat window is opened. As soon as
Page 143 and 144: three examples in the form of excer
Page 145 and 146: Example 2. Excerpt from an IM log s
Page 147 and 148: Example 3. Excerpt from an IM log s
Page 149 and 150: immediate feedback in the heated di
Page 151 and 152: Acknowledgements Thanks to Monica D
Page 153 and 154: Research paper P4 Title: The wiki a
Page 155 and 156: The wiki as an integrative tool in
Page 157 and 158: type of use can be seen as an examp
Page 159 and 160: ecome integration, and we identifie
Page 161 and 162: project. Typically, a clean-up was
Page 163 and 164: 5.1 The wiki as a knowledge reposit
Page 165 and 166: 6. Conclusion We have shown how pro
Page 167 and 168: Research paper P5 Title: Using Proj
Page 169 and 170: Proceedings of the 42nd Hawaii Inte
Page 179 and 180: Research paper P6 Title: Shared tim
Page 181 and 182:
Shared timeline and individual expe
Page 183 and 184:
presentation. In 2008, there were 1
Page 185 and 186:
congruent’ to sets that seem to o
Page 187 and 188:
team members and the co-constructiv
Page 189 and 190:
Research paper P7 Title: A Model of
Page 191 and 192:
A Model of Retrospective Reflection
Page 193 and 194:
420 B.R. Krogstie Fig. 1. Shared ti
Page 195 and 196:
422 B.R. Krogstie information about
Page 197 and 198:
424 B.R. Krogstie and to express ho
Page 199 and 200:
426 B.R. Krogstie 4.2 The Temporal
Page 201 and 202:
428 B.R. Krogstie in combining them
Page 203 and 204:
430 B.R. Krogstie Fig. 3. A model o
Page 205 and 206:
432 B.R. Krogstie 20. Hutchins, E.:
Page 207 and 208:
Research paper P8 Title: Supporting
Page 209 and 210:
Supporting Reflection in Software D
Page 211 and 212:
2 Background In this section we bri
Page 213 and 214:
There are 3-5 students in the teams
Page 215 and 216:
4 Research Method The research repo
Page 217 and 218:
5 Findings In this section we draw
Page 219 and 220:
As a consequence, ‘startup coding
Page 221 and 222:
The type of data involved included
Page 223 and 224:
potentially negative effects is if
Page 225 and 226:
unfolded may shed light on the proc
Page 227 and 228:
5. Lyytinen, K. and D. Robey, Learn
Page 229 and 230:
Appendix B: Other research publicat
show all

The work-reflection-learning cycle - Department of Computer and ...

Create successful ePaper yourself

Delete template?

Save as template?