knowledge (in working life) has become untenable. ... learning scenario defines a software project in which students learn .... with tele-collaboration techniques to support the project ..... information rate than email or a chat tool, it is much faster ...
Constructionist Learning in Software Projects
Schroeder, Brunner, Deneke
1
Constructionist Learning in Software Engineering Projects
There is a general agreement as we approach the next century that our society is changing into a knowledge and information society. There will be new opportunities and new challenges in all dimensions of our lives. One of the challenges will be that we will (have to) continue learning to keep up with all the changes which take place in ever shorter periods.
U. Schroeder, M. Brunner, M. Deneke Juni 1998
Abstract On the verge of the information society of the next millenium we are looking for innovative learning scenarios to prepare students for their future professions including the challenge of lifelong learning. In this article we describe our software engineering class which is designed as an open, self-directed, constructionist learning scenario in the context of authentic problems. The concept of this class has been continuously evaluated in various ways: Interviews with participating students, former participants, their employers, and local software industry. Emphasis of the '97 evaluation has been laid on the utilization of internet services. As a result we design the '99 class substantiating the integration of synchronous services like application sharing and audioconferencing to further encourage telecollaboration.
Lifelong learning has emerged as one of the major challenges for the global knowledge society of the future. The previous notions of a divided lifetime of acquiring knowledge (in school and universities) and applying knowledge (in working life) has become untenable. Professional activities are knowledge-intensive and new technologies evolve faster so that it can not be expected to acquire all the knowledge needed for a lifetime in advance. Lifelong learning has become integral part of work activities in the form of continuous engagement in acquiring and applying knowledge and skills in the context of a current task at hand. These challenges must be met by new curricula in which the process of learning is self-directed and open. Learning must take place in the context of authentic problems. Techniques to assess the right information in the moment when it is needed must be trained.
1 SOFTWARE ENGINEERING EDUCATION BASED ON CONSTRUCTIONIST LEARNING THEORY 1 2
SOFTWARE ENGINEERING CLASS......2
Current theories of constructionist learning [Papert93, Kafai95, Resnick89, Norman93] make fundamental assumptions about learning as
2.1 SOFTWARE ENGINEERING LECTURE ........2 2.2 SOFTWARE ENGINEERING PROJECTS........2 2.2.1 Domain Analysis ...........................3 2.2.2 Software Design ............................4 2.2.3 Implementation and Testing...........4 2.3 DISTRIBUTED TELE-COLLABORATION ......4 3
• a process of knowledge construction, not of knowledge absorption, • knowledge-dependent,
EVALUATION ...........................................4
• tuned to the situation in which it takes place,
3.1 3.2
GENERAL FEED BACK ..............................4 UTILIZATION OF COMMUNICATION- AND INTERNET SERVICES ...........................................5 4
• needing to account for distributed cognition requiring knowledge in the head and knowledge in the outside world, and
SYNCHRONOUS INTERNET SERVICES 7
5
LEARNING IN SOFTWARE PROJECTS8
6
ACKNOWLEDGEMENT ..........................9
7
REFERENCES ...........................................9
Software Engineering Education based on Constructionist Learning Theory
• affected as much by motivational issues as by cognitive issues To meet the requirements of lifelong learning our software engineering class has been designed as an open educational setting with opportunities for self-directed learning in the context of authentic problems. New information technology, e.g. the utilization of internet services, is included as the means for 1
Constructionist Learning in Software Projects
Schroeder, Brunner, Deneke
mutual balancing of expertise within a team. This helps constructing a mental model of the presented educational material.
assessing information at the right time (see [KnTrSc96], [Schroeder95], and [ScBr94] for discussions of the utilization of the Web in university classes). The notion of shared cognition [ReLeTe96] is met by experimenting with new forms of distributed telecollaboration. More key qualifications include efficient utilization of new media for working in the information society.
2
We basically teach the process of objectoriented software development starting from the notion of quality and possible tradeoffs between different criteria. We roughly introduce alternative project management techniques (process and product). This leads to the definition of a software process (team structure, project control like milestones, software configuration etc.) for the own software project. The main focus is laid on assuring the quality of a product.
Software Engineering Class
Lectures as a form of teaching do not fit well in the picture of constructionist learning, although there are situations, when lectures are adequate to present information to a large number of students in efficient time. Teaching programming and software engineering requires additional forms of education. We follow the constructionist idea of learning in the context of real world problems while working on artifacts. Therefore the main learning scenario defines a software project in which students learn, adapt, apply and assess modern software methods and tools while designing and implementing a software system. The class is described in more detail in [8].[BrKüSc96].
The focal point for object-oriented software development are the UML notation and its associated OOA and OOD methods. Students’ experiences with object-oriented languages can be taken for granted, because these are taught as primary languages in our computer science curriculum. For the purpose of analysis the participation of envisioned system users by means of use cases and scenarios are introduced. The documentation of the dynamic scenarios offer two views: • A user interface prototype is used to discuss matters with domain experts • interaction diagrams are the means for communication within the project team
The class consists of a three hour per week lecture (during winter semester), and seminarlike working groups specializing on certain topics of software development (meeting several times per semester depending on students demands during project work), and a one year project, which is carried out in teams of six to seven students.
Design and implementation issues include different object models (Smalltalk, C++, Java, Eiffel). Advanced topics like concurrency, distribution, client/server architecture and persistence are discussed. Advanced objectoriented topics like combining different structuring mechanisms (inheritance, polymorphism and dynamic binding, composition, genericity) are also introduced.
The class is taught by one professor and three teaching assistants and attended by approximately 40 to 50 graduate students. It is credited seven hours per week, which accounts for about 10 % of the exam requirements within the computer science diploma. The evaluation and grading is realized during the software projects by assessing all the software documents (e.g. requirements specification, project planning, including quality assurance like test specification, documentation of design models etc.) in conjunction with three 90 minute oral examinations.
2.1
Design techniques stress the utilization of software design patterns and models like the model-view-controller paradigm. Further topics include library design, frameworks, and formal methods for specifications.
2.2
Software Engineering Projects
Projects are the core ingredients of our software engineering class. Students form teams of six or seven members to carry out the project work as a small, autonomous software company. The assignments are real world professional projects, which are disposed by industrial and administrative customers. Involving external (industrial) project partners leads to
Software Engineering Lecture
The cognitive learning objective of the lecture (knowledge about software development methods) plants a seed for ongoing selfdirected learning during the associated project. Applying the methods in a project requires reflection and transfer of knowledge and 2
Constructionist Learning in Software Projects
Schroeder, Brunner, Deneke
• June: object oriented design • September: final product including documentation and validation • November: product fare The results of each phase are presented and discussed with the faculty of our department (reviews and oral examination). They are also documented in different notations (prose, UML, formal (mathematical) specification). Different forms of documentation and additional information sources like protocols of team meetings, are integrated as a hypertext and can be reached through WWW by team members, customers and tutors.
• higher motivation of the students, because their project effort will not be thrown away after grading. Customers have a real interest in a high quality product. • higher communication efforts, which are more difficult to solve (compared to inhouse, academic problems), because different stakeholders with diverse vocabulary and background are involved. • Clarifying the requirements is carried out on the job at the location of customers. Students get a first insight into working life of different domains. The software development process is organized as an iterative, incremental life cycle. Still there are three main phases of a project consisting mainly of analysis, design and implementation. Reverse engineering and software maintenance are not within the scope of the class.
Each project team is tutored by one of the departments faculty members, who do not actively participate as team members, but rather are external advisors and controllers of quality, assuring the proper application of methods and tools and aiding in problem situations.
The project emphasizes that software production is inherently interdisciplinary and involves different communities of practice. Good computer scientists must be open to learn about the domain of the systems application, and communication skills are key qualifications for computer scientists. To give a better understanding of the diverse kind of projects here are some examples (the customers in brackets) : • Airmen Information System, an information system for private pilots (sidata) • Management system for fertilization (BASF) • Intranet-based project management & team information system (sd&m software consulting) • Public transport information system and support for a bus-on-demand system (Main-Taunus-Verkehrsgesellschaft MTV) • Multimedia product catalog including net based access and order facility (sidata) • Team Information System – a distributed componentware prototype (Siemens AG)
2.2.1 Domain Analysis The first project phase has the purpose of determining the systems requirements and planning the activities necessary to achieve that goal. It consists of inception (specifying the vision of the project) and the elaboration (planning the necessary activities and required resources and specifying the features of the system). Our teams are engaged to use a CASE tool supporting the UML notation. Use Cases and scenarios are the starting point to capture the projects vision. These are further elaborated by finding classes and their responsibilities. Scenarios are further refined to result in user interface prototypes, which are well suited to validate the design of the system in an early stage. We demand that documentation is produced in the language of the application’s domain. With this excessive form of domain analysis the first version of reference and user manuals are written before the actual system development starts. Use cases and scenarios are also used as a first specification of test cases, which are to be refined in the following phases.
The team members choose their team structure, normally resulting in a democratic form, but some structures evolve with the ongoing project, in some cases even chief programmer teams. An additional and optional class “Team Training” is taught by members of the didactics department and helps students to enhance their team working skills. Projects start in November and end in October of the following year. Teams are free in planning their schedule around four compulsory milestones: • March: Final requirements specification, OOA model, project planning
Beside the functional requirements organizational issues include: • Planning the sequence of activities • Planning the measurements and control • Planning the quality assurance • Describing the legal conditions of system application
3
Constructionist Learning in Software Projects
Schroeder, Brunner, Deneke
state of their teams by watching the evolving documents and reading the protocols of team meetings. Teams established project repositories and basic version control at the university servers and could access the information from different locations.
2.2.2 Software Design After the first description of the system in form of classes, representing the systems functionality as viewed from the outside (users view), these classes are now revisited, and the system is restructured. During software design, architectural issues represent strategic decisions like efficiency, language issues, flexibility, maintainability, decisions regarding common standards, policies etc.
In addition to tele-collaboration modern faceto-face cooperation could be experienced in our multimedia software lab, a meeting room with computer equipment, data video projector, video camera and VCR, metaplan tools, and whiteboards. Students were encouraged to present their results to the other team members using online slide presentations and prototypes or web browsers and internet access. A supplementary class "Presentation forms in software Projects” was taught by faculty of the didactics department.
In this phase communication shifts from customer/team into team internal. The language is computer science specific (UML, design patterns, programming language libraries). Products of this phase are documented with a CASE tool, which is also used to check consistency of the models of diverse levels of abstraction. Main focus is put on the use of software design patterns to ensure reuse of well proven designs.
3
In the two following sections we describe the evaluation of the software engineering projects in general as well as the utilization of internet services in more detail.
2.2.3 Implementation and Testing After completing a good design the last project stage of implementing and validating the system should normally be executed fast and without major problems. Class frames can automatically be generated by CASE tools and coded separately and distributed by different team members. Our experience shows that this phase still takes much longer than expected. This is due to further learning efforts (new languages, working environments and tools) and extensive testing.
2.3
Evaluation
3.1
General feed back
From interviews with participating students during and after the projects we know that our students appreciate the concept and outcomes of project work very much. The opportunity to work on real world professional problems within a team of about six persons and being able to successfully design and implement a complex software product by order of an external non-academic customer, is extremely enthusiasting for the students. The motivation to work hard is very high. Besides the new software engineering concepts and tools learned (knowledge), especially the practical experience of complex team work with all its facets is important according to the opinion of the student participants. Obviously, students extend their social skills. This overall very positive judgements are agreed to by former project participants, when asked after a few years of practice in industry.
Distributed Tele-collaboration
As a preparation for the future information society we offer the opportunity to experiment with tele-collaboration techniques to support the project work. In 1997 we started a pilot project together with the German National Research Center for Information Technology (GMD-TKT): Students can dial in from home PCs (via modem or ISDN), transparently use internet facilities, establish a document repository at the university and communicate with each other or with their customers via email.
Interviews with employers also substantiate the great success of our concept of software engineering education. Especially the combination of profound software engineering knowledge (e.g. object orientation, UML, design patterns) and the ability to conduct productive group work with all its challenges is thought to be of high importance to the software industry. Some employers stated that they could see a difference in the computer science students who took part in the projects and those who did not. Students with
The utilization of internet services were explicitly encouraged by offering all course material as web pages with links to further information. Project home pages were compulsory as exploration point for team members, their tutors and their clients. We used newsgroups for information distribution (invitation to talks about SE topics, announcements of the availability of new tools etc.). Tutors were always reachable via email and could keep up to date with the project 4
Constructionist Learning in Software Projects
Schroeder, Brunner, Deneke
engineering students of the year 1997 intensive interviews were conducted in spring 1998 with nearly the half of the student participants. Additionally written documents (e.g. registration, protocols of meetings) were analyzed. The 35 participants of 1997 worked in six separate teams, all with their own project.
experience in software engineering project work were thought to be more easily able to productively work in professional software teams. We do not know whether our students develop a better willingness and ability for lifelong learning, because our attempts to integrate learning concepts into the project work are too new to be evaluated yet.
As background information for the assessment we investigated how much time was spent in (smaller or bigger) working groups and how much students worked solely on their own. Secondly we investigated where these different forms of project work took place: At the Darmstadt University of Technology or at home or at other locations. The results are presented in detail in [Deneke98].
In several workshops with software producers from the Rhein-Main area, our industrial partners presented their projects and policies, and we presented our concepts of education. The discussions were aimed at clarifying what employers would expect from a good software engineer. Beside profound theoretical computer science knowledge professionals wish that future employees know about economy and take responsibility of their activity in a software team. These are expected to have good social skills and are able to assess and evaluate new methods quickly. Expertise in a certain method is less important than the ability to find appropriate information, evaluate new methods and make good decisions based on few information. Our concept of project-based constructionist education was very well approved by the local software industry.
Roughly half of the time needed for project work is spent as individual work (44%). This work is carried out at home most of the time. Only about 10% of individual work is accomplished at the university. The portion of individual work increases during the project: It comprises about 25% in the first phase of analysis and about 60% in the third phase of implementation and testing. About 20% of the overall project work is accomplished in small teams of two or three students, mostly at home and only in rare cases within university facilities. This form of project work predominates in the design- and implementation phase.
Despite of the overall success of our projects some drawbacks have to be admitted: One problem is the high working load for the students and their tutors and the fact that projects sometimes need a longer time than originally planned (most teams extend their project for about one month, some for two or three). One reason is the fact that students learn a lot on demand, and the time needed for learning can not be planned in advance. Also prior to our project students have no experience in estimating the time they need to complete a step of development.
100% 80% 60% 40% 20% 0%
About 10% of the participants do not successfully end project work but leave the project groups in advance, sometimes because of conflicts between students, sometimes because they leave the country to take terms at a foreign university or go back to their university after spending one semester in Darmstadt (e.g. ERASMUS students). In rare cases (one every two years) whole groups give up their work.
3.2
Analysis
Design
Whole team
2 -3 persons
Implementation Individual w ork
Figure 1. Working forms in the three project phases
About one third (34%) of project work takes place at the university in working-groups with all members of the team. In the first phase the portion of teamworking and discussions in larger groups is very high (60%) and goes down to about 15% in the third phase of implementation and testing. Here individual work is dominant.
Utilization of communicationand internet services
In order to assess the utilization of internet and telecommunication services by the software 5
Constructionist Learning in Software Projects
Schroeder, Brunner, Deneke
a week by one student. Despite the fact that working at home was more attractive than working at the university the internet services were 1,5 times more frequently used from within the university than from home. This is probably due to better bandwidth and lower (no personal) communication costs.
From this data we learn two important lessons: Individual work and team work are nearly equally important and 2/3 of project work is carried out at home. The university is important as a meeting place for group discussions with all team members, which took place three or more hours weekly (most during analysis, least during implementation). From our interviews we can give some reasons for the dominance of working at home: the working atmosphere is better at home than in the university. Normally the students are free to work whenever they want to at daytime or at night. They are not disturbed by others and they don’t disturb other students. Very often the private computers and software tools are sufficient for project purposes (in 1997 80% privately possessed Pentium PCs the rest 486 PCs). Only if the private computers or software tools are insufficient, students tend to use the equipment of the computer science department.
The internet services used by the students were: World Wide Web (WWW) for the search of relevant information concerning e.g. software tools and methods especially in the first phase of project work. In the analysis and design-phases the WWW was used to publish the protocols of the weekly group meetings as well as the evolving versions of the software documents. Email especially for sending information of one group member to the others. To a lesser extent email was used for the communication with the customer or the tutors. Email was not adequate for complex and time-sensitive communicationwhich was realized by face-to-face-meetings instead.
Figure 2 shows where the participants of the 1997 software engineering projects lived and whether they had a private internet access via Computer, Modem (or ISDN-Card) and telecommunication. About 50% live within the City of Darmstadt, additional 16% near to it (circle of City tariff in figure 2) and the rest within 50 km distance to Darmstadt. All students possessed a private telephone and a PC. More than 3/4 of the participants had the opportunity to access the internet via modem and telecommunication line to use internet services from their homes. Additionally all students had the opportunity to use the internet from university facilities and at least 85% did so.
File transfer (FTP) was used to establish the central project repository and to synchronize on the latest versions of the software components. Exchanging files via floppy disk was no longer necessary. FTP was also used to download new software components via internet from the software manufacturer. Newsgroups were available but rarely used, partly because of technical problems. One important characteristic of the internet services used is the fact that they all are so far asynchronous. In the 1997 project there were no synchronous internet services available to realize e.g. audio-conferencing, videoconferencing or document or application sharing. The internet services used were thought by the students to be of high value to conduct the projects, and only one untypical small project group did not use internet services at all. Nevertheless, if complex topics had to be discussed, students did not use internet services but rather arranged face-toface-meetings which were easily organized, because many students lived nearby and met regularly for other classes at the university.
Figure 2. Students Residences
On the average internet services were used for about 1,5 hours per week (15% of the overall workload). Irrespective of the 15% which did not use the internetat all, there were some students who used it for only half an hour per week, the maximum were five hours
While working at the university few students used the extra opportunities of the multimedia meeting room (computer equipment, data 6
Constructionist Learning in Software Projects
Schroeder, Brunner, Deneke
For the future, we plan to additionally enable project teams to have short term telediscussions and solve shorter problems using the same techniques and tools they use in the meetings, but now in a distributed manner via internet.
video projector, video camera). Most groups were rather conventional in conducting their sessions: they used paper, pencil and the blackboard, some groups used additional tools like metaplan. Most students believed that conventional tools were quite sufficient for their discussions and decision making. But many groups thought that it would be very helpful to have immediate access to a computer during the sessions.
4
The first step in this direction is to provide a form of synchronous working on a single document. These documents will probably be software analysis and design documents. They are in their graphical nature more suitable for the parallel use by several team members than documents consisting mainly of text parts. The proper technique for this synchronous editing is application sharing. This is established without making the tool itself group–aware. The CASE tool will still run on one workstation or PC, but its screen and IO devices are split and reproduced on all PCs taking part in a virtual meeting.
Synchronous Internet Services
There has been very good feed back for the presented concept of software engineering education in general. Still, when analyzing the results of the evaluation you can clearly state, that not all the goals that we mentioned in the first section of this paper have yet been reached. Especially establishing a solid ground for lifelong learning can still be worked out further.
In order to reach a real synchronous state we will also include audio communication into our scenario. Audio connection has a higher information rate than email or a chat tool, it is much faster and cheaper than a video connection. Audio connections can be realized in two ways. The first one is to use an internet based conferencing tool, the other one is telephony in its simplest form or as a telephone conference.
Some hints have been given by the students of the 97 class, when they were asked what they thought about synchronous internet services like audio-conferencing and application sharing. Almost all students had no experiences with synchronous internet services so far, still many thought it worthwhile to experiment with such services within the projects in the future. The synchronous tools have to fulfill very high standards: They have to be cheap and available to all students, to work with them must be easily learnable, they must be fast and stable. Some students critically mentioned that in the next future holding face-to-face-meetings will remain the choice at hand.
The technical resources we plan to use on the client side are quite cheap. Most of our students are equipped with Pentium PCs including sound cards and speaker devices. To complete the audio hardware there is only a microphone needed, which is nowadays included in every soundcard package. Optionally a headset could be used.
In order to allow our students to develop software in distributed working environments we are setting up a new technical support infrastructure. Beside the use of asynchronous tools like email and WWW, we plan to include synchronous services. As stated above, currently students meet face-to-face to discuss analysis and design models of the envisioned system. This is partially essential, because they use a CASE tool (e.g. Rational Rose) to visualize and edit graphical representations of system models. These tools typically do not support the concept of distributed collaboration of team members. So students meet in the conference room, only one person sitting in front of the laptop with the diagrams projected by the data video projector. The other students can discuss the model, suggest enhancements or modifications, but only one person can actively adjust the model.
The software requirements are also quite limited. Conferencing software is included in many web browser packages, which are (at least for personal use) free of charge. These include for example Microsoft Netmeeting or Netscape Conference, which provide the base for application sharing according to the ITUT120 standard or the H.323 standard. The option to use traditional telephone services for a conference just requires a telephone bridge at a defined location. Here we can use existing resources of our project partners at the GMD institute. Clients just use ordinary telephone devices. Another, primary asynchronous aspect of software development that we will support is a 'shared workspace' which supports document upload, event notification and group management. We are planning to use the web 7
Constructionist Learning in Software Projects
Schroeder, Brunner, Deneke
based system BSCW (Basic support for collaborative work) that allows for transparent usage at the work place or from home. Currently one member of a project team is assigned to be responsible for configuration management. This person manually performs the task, only supported by basic version control (RCS, SCCS) on a central file repository.
5
which can provide sufficient ground to allow non-programmers (in the traditional sense of programming) to build user interface prototypes. The activity of a software engineer during domain analysis can then concentrate on building the right components to enable the user to construct his view of the envisioned system. By building these components the software producer learns about the domain of the systems application. This is equivalent to developing a common glossary for the specific domain.
Learning in Software Projects
The next step of enhancements must include establishing the concept of (lifelong) learning into our software engineering class. There are different aspects of learning involved in software projects: • Customers and software developers should mutually learn about the domain of their counterparts • Students learn to apply new methods, while working on their current tasks • SE students reflect about their new experiences and their working and learning methods
In order to effectively support the mutual learning, information must be available at the right time and the right level of detail. Every aspect must be tailored to the knowledge of the current reader. New media like WWW in connection with dynamic media and simulation should help to provide adjustable learning environments. Also communication technology plays an important role to support collaboration between different domain experts. But most important will be the efficient support of a commonly designed information space around the evolving artifact, which includes prototypes, sample sessions, a glossary of terms etc.
We understand design1 as a process which is lead by stakeholders of different communities of practice (customer, future system users and software development team). Design activities incorporate personalized and collaborative aspects, and combine technical and aesthetic elements. Therefore design must be carried out as an argumentative process, involving ongoing negotiations between all participating stakeholders. It is crucial that the evolving artifact is publicly accessible and users can actively participate in the evolutionary and iterative system design. One of the important problems to solve will be the motivation of users to actively take part in the design process. This can only be achieved by providing evidence that the overall quality of products is significantly better so that users profit directly from their design activity.
The second aspect of lifelong learning comprises the learning environment for learning-on-demand. Again it is crucial that information about software engineering practice is handily available at the moment of breakdowns (situations when development stops, because some piece of information or knowledge is missing). So far we have tried different approaches to support task-driven learning. At first we started threads in a special purpose newsgroup and wanted our students to build their own FAQ directories. This was not successful, partly because newsgroups are passive and leave the information gathering to the reader, partly because newsgroups could not be used outside of the university. But the main reason seems to be the learning culture: students expect the material to be presented by their teachers instead of actively learning by exploring new topics and teaching themselves.
We assume that the user activity can be pushed as far as to enable end-users to design their own view of the system’s user interface to simulate the use cases and scenarios they now describe as prose (“Use Case driven approach” [JaBoRu97]). When users are asked to build user interface prototypes, they must learn how to program prototypes (without actually using a programming language). We are to develop new methods and design tools utilizing software components like JavaBeans,
The next year we organized working parties with delegates of the project teams to discuss special topics like project management or how to work with a certain tool. These working parties were not as successful as we hoped, because again interest on a topic arose at different times in the different project teams. The intention to learn and its associated
1
In the following the term ‘design’is used as a general term of creating artifacts and must not be confused with the (limited) ‘design phase’ of traditional software engineering (software architecture and implementation issues)
8
Constructionist Learning in Software Projects
Schroeder, Brunner, Deneke
activity was not evenly distributed among the project teams.
[Papert93] Papert, S.: "The children's machine: Rethinking school in the age of the computer", New York: Basic Books, 1993.
We are still to find an optimal scenario to foster learning-on-demand, when information and learning opportunity is available at the exact right time, when breakdowns occur. This will comprise possibilities to use and develop an information space about lessons learned during the projects. It will also be necessary to change the students attitude and learning culture.
[Resnick89] Resnick, L.B. (ed.): “Knowing, Learning, and Instruction: Essays in Honor of Robert Glaser, Lawrence Erlbaum Associates, Inc., Hillsdale, NJ, 1989 [ReLeTe96] Resnick, L.B., Levine, J.M., Teasley, S.D. (ed.): “Perspectives on Socially Shared Cognition", American Psychological Association, 3rd printing, April 1996 [JaBoRu97] Jacobson, I., Booch, G., and Rumbaugh, J.: “The Objectory Software Development Process“, ISBN: 0-201-57169-2, Addison Wesley, December 1997.
The third aspect is dealt with by a final working party after termination of all projects, when students are asked to reflect about their new experiences and about the way of working in a team and learning in our class. This metacognition is one of the most important learning objectives, because later in the professional working context there is rarely an opportunity for this kind of reflection. Some experiences comprise how to deal with team members coming to meetings without being prepared and how to balance different knowledge in inhomogeneous teams.
6
[ScBr94] Schroeder, U., Brunner, M. “Utilizing WWW and Mosaic for Computer Science Education“, Proceedings of the Workshop on Teaching and Learning with the Web at the 1st Intl. World-Wide-Web Conference, Geneva, Mai 1994 [Schroeder95] Schroeder, U. “HyperScript innovative educational use of WWW“, Proceedings of the Workshop H: Teaching and Training on the Web at the 3rd Intl. WorldWide-Web Conference, Darmstadt, April 1995
Acknowledgement
We would like to thank Prof. Henhapl for his readiness to experiment on innovative learning opportunities and his valuable input for this paper. Special thanks goes to H.-J. Burkhardt of GMD-TKT for sponsoring the telecooperation project.
7
References
[BrKüSc96] Brunner, M., Kühnapfel, B. and Schroeder, U. “New Media in Software Engineering Education“, SoftwaretechnikTrends 16:1, p.16-20, 1996 [Deneke98] Deneke, M.: “Zur Nutzung von Telekommunikationseinrichtungen im Software-Engineering-Praktikum 1997“, Projektbericht, HDA, Mai 1998, in German; to be published as GMD report [Kafai95] Kafai, Y.: "Minds in play: Computer game design as a context for children's learning." New Jersey: Lawrence Erlbaum Associates, Publishers, 1995. [KnTrSc96] Knierriem-Jasnoch, A., Tritsch, B. and Schroeder, U. “Reflection on WWW Functionalities for Educational Purposes“, Comput. & Graphics, Vol. 20, No. 3, Elsevier Ltd, pp. 435-443., 1996 [Norman93] Norman, D.A.: “Things that make us smart”, Addison-Wesley Publishing Company, Reading, MA, 1993 9
