Gaining hands-on experience via collaborative learning: Interactive computer science courses

In this paper we primarily report on the practical outcomes of Software Studio undergraduate course, but also on a graduate Software Engineering for Internet Applications course, both of which are taught collaboratively by IT and non-IT faculty members. In the latter, students are assigned to projects proposed by actual customers and work together in teams to deliver quality results under time and resource constraints. We are interested in the learning results, such as skills acquired, e.g. by analysing the interaction between students and customers to determine how and to what degree the students transform through project based collaborative learning. As for the former course, we intend to determine the added value of collaborative teaching, aiming at equipping the participants with both technical and non-technical skills required for their prospective jobs. The primary goal is, therefore, to allow students to manage a relatively large number of tools with little prior knowledge and having to work out how to obtain detailed information about given features when required. In other words, students have to understand the key ideas of web application development in order to be able not only to apply technical knowledge, but also to successfully interact with all the stakeholders involved.


INTRODUCTION
This paper is concerned with the practical outcomes of two courses taught at a Computer Science and Engineering university. We focus on Software Studio (SS) -an undergraduate course, taught collaboratively for two years, but also discuss some benefits of a graduate course in Software Engineering for Web Applications (SEIA), taught collaboratively for 6 months.
One of the reasons for collaborative teaching in our case is adding the communicative aspect -the interaction and interconnectivity between stakeholders and the sociocultural context in which they act and interact sharing experiences (Vygotsky's focus, as described by [1]).
Generally, learning becomes a reciprocal experience for the students and teachers and when courses are taught over a number of years, they evolve, change with the differing students and other stakeholders involved, as well as with the experience gained by the instructors. Following Vygotsky we assume that since knowledge construction takes place within social context, participation in a given course involves student-student and "expert"-student collaboration in solving real-world problems or tasks that are shaped by each individual's culture and relate to each person's language, skills, and experience ( [2], p. 102).

RESEARCH QUESTIONS
The pedagogical method applied is that of collaborative teaching/learning, with the main characteristics being a common task or activity, small learning group (5-14 students), co-operative behaviour; interdependence; and individual responsibility and accountability [3]. The instructor team consists of one IT instructor and one non-IT instructor, respectively; with the latter responsible for the 'soft' and interactional aspects of the course, including negotiation and change management. We are interested in finding out collaborative learning outcomes and analysing the interaction between students and customers, which are then directly reflected in the changing course content and progress reports. For this we carried out pre-and post-course assessment of the SS course participants, applying certain predefined characteristics and drawing on so-called transactional analysis (TA) [4]. In particular, in student assessment, we resorted to the ego-state Parent-Adult-Child (PAC) model [5] in order to determine how and to what degree the students transform through project based-and collaborative learning, especially when interacting with real customers.
To encourage peer evaluation and team spirit development, we made use of team evaluation forms (work progress, individual member evaluation, etc.) developed by [6] Oakley et al (2004). Drawing on reference's [7] theory of social learning we also reflect on the challenges related to team building and team work in the Japanese culture, due to, e.g., lack of criticism and confrontation in customer relations; or honest evaluation of team co-members, peer-rating and the like. Reference [7] stated that we learn through interactions with others. In case of students, learning takes place through interactions with their peers, teachers, and other experts in their field. A teacher, or a coach, but also an external expert (or a customer in our case) plays a role of a learning facilitator, creating the necessary environment for directed and guided interactions to take place. According to [2], social interaction plays a fundamental role in the process of cognitive development. Vygotsky  who has a better understanding or a higher ability level than the learner with respect to a particular task, process, or concept (in our case an instructor, coach, customer, or a fellow student). The Zone of Proximal Development (ZPD) is the distance between a student's ability to perform a task under guidance and/or peer collaboration and that student's ability to solve the problem at hand independently. Vygotsky claims that learning occurs in this zone (see Fig. 1 for Vigotsky's model as applied to the SS course under consideration). The ego-state model applied is based on reference's [4] Transactional Analysis in psychotherapy and includes three states, namely: • Adult ego state (A) that refers to one's thinking, feeling and behaving in the here and now mode, appropriately to any stimulus. When one is in the adult ego state, one is in full contact with and is responding to the here and now in an adult way.
• Child ego state (C) that is judged by the way a person responds to the here and now as if it were an event from the past (acting in the same/similar way as when one was a child).
• Parent ego state (P) is demonstrated in situations when one responds as if one were the parent figure rather than responding directly and accordingly to the situation. One is said to be borrowing one's parents' [old] way of being [4] [5].
We conducted interviews with the two technical course instructors, and carried out post-course student selfevaluations. Our research questions were the following: • What are the benefits of collaborative teaching and learning?
• What are the challenges of multi-directional communication in software development?
• What are the tangible course outcomes both from the student and instructor perspectives? What skills emerge as crucial for software development?
• What are the team building and teamwork skills required and acquired?

A. Software Studio Course -An Overview
In the SS course, students are assigned to one of several projects proposed by actual customers (companies and other external organisations) and work together in teams. Each team is guided by a coach (an expert from a given industry) who provides advice during the development phase. Teams report to the instructor every week, hold meetings with the customers as necessary, and report on their progress and results at two (interim and final) presentation meetings. Also, specific documents produced at each step of the development process are submitted. Since each project team works for an actual customer, results must be produced and delivered to tight deadlines. All students in a given team have to be prepared to actively and responsibly participate in their project. The main objective is to understand the challenges related to developing software that satisfies specific functionality and quality. Students gain first hand experience of project management in software development, conducted under certain constraints, such as limited resources (people, time, equipment). Unlike in regular, theoretically oriented courses, student experience the necessity to timely respond to uncertain circumstances, including identifying cross-functional roles and communicating information correctly. Students working in teams have an opportunity to apply knowledge and skills gained also in other courses to solving realistic and practical problems, guided by instructors and coaches. Moreover, they analyse a given problem and corresponding application domains, making sure to understand the requirements and design software architecture in order to be able to develop the necessary methods for task/software implementation and to conduct usability test for design optimisation. Each student should also understand the surrounding environment of a given problem, including the network, hardware, and software features. Their activities are also oriented toward gaining project management skills and overall understanding of organisational issues.
The project work is typically carried out for an external customer or a potential customer. Technical advisors assist the instructors in evaluating student work for content and correctness. Another focus is placed on activating students' multi-directional communication with teachers, fellow students, coaches, and customers, as well as their ability to seek solutions to and solve problems on their own initiative and learning. There are currently two coaches from industry; and their role relates to the customer order and its content and the steps in software development. They are not responsible for the educational aspects and management of students; however, although they do get involved to a certain extent in education, too, taking into account the characteristics of participating students. The instructors focus primarily on student education and overall project management.

B. Software Enginnering for Internet Applications -A Course Overview
Industry-oriented IT education -especially at the master level -has to ensure that the graduates can assume the role of systems architects and lead system development projects in domestic and international settings. Since software industry is growing very fast, it is practically impossible to study all the tools in detail that are implementable in new software projects. The primary goal is, therefore, to allow students to manage a relatively large number of tools without knowing much at the start and having to work out how to obtain detailed information about features, as and when required. In other words, students mainly have to understand key ideas in order to be able to apply them in practice.
One of the key tendencies in the software development field is the priority given to Web applications. This results in an ever-increasing demand for professionals who can design large Web systems. The aim of this course is, therefore, to study current concepts and methods for Internet application engineering. The course is taught in English (English as the lingua franca as 3 nationalities are involved) by one technical instructor (a computer scientist, head of the software engineering lab), one non-technical instructor (an expert in language, communication, and business discourse who focuses on soft skills, interaction with stakeholders, negotiation process in the context of software engineering, change management, aesthetic design and the user perspective), as well as one substitute technical instructor (with different IT background).

C. Muti-directional interaction: challanges
As mentioned before, the SS course offers interaction with real customers (see Fig. 2). The "contract" with customers expresses agreement to show understanding for the fact that a given project serves an educational purpose; therefore it is not a genuine project per se (which may not sometimes be entirely comprehended when placing expectations in the final product). Students interact with their customers in diverse ways; with customers differing from year to year and representing different lines of business, which implies differing types of interaction as one of the intentional course aims (the course is still in the experimental phase). It started with local businesses (organised and individual) and is now expanding to include customers from other parts of Japan. Structured companies favour continual interaction, so students have to adjust accordingly. They are guided by both instructors in terms of which method of interaction to use, but mostly are able to find out themselves what is best. Feedback from the customers (mostly by email) comes directly to the mailing list and the interactions are monitored by the instructors. Although face-toface meetings are preferred and desired, because of time constraints and logistics reasons they may not take place regularly. Usually, local companies visit every week, but if they are based in Tokyo, then regular face-to-face contact becomes difficult. Students are not allowed to initiate personal interaction with customers.
In every class students communicate with both instructors and submit weekly progress reports, identify progress, problems, and methods of approaching problems. The instructors intervene, when necessary, giving instructions on how to proceed, checking documents prior to passing them on to the customers. This allows for another chance to guide students through the process, as they often do not know how to produce business documents.
Since students are reluctant to speak about problems or are unable to express what is happening in words and only at the last moment admit that there is something wrong, a close watch via trustworthy students (or friends of the participating students) is necessary -in this way the instructors can indirectly collect information about the problems encountered. A project management tool is used to share files and course related online resources, with the content monitored by the instructors. It is for students to use for important project deliverables, not necessarily for team meetings. The relationship among 2 instructors (as co-managers of the project), 2 coaches (as technical and business advisers), and students (as software engineers-to-be) is structured in such a way as to put the external customers (such as a bus company, or farmers, with no IT person on board) and their needs (i.e. also issues and problems) first and to solve them professionally using ICT skills. But in order to relay problems in software terms, it requires considerable technical and professional advice from the two coaches. From the educational perspective, too much advice, however, would change the direction of the software development that the students should learn to negotiate about with their respective customers. In this process, they are to collaborate together to make sure that external requirements/requests are met and problems solved the way that is desired by the customers and, simultaneously, doable in terms of ICT skills. Sometimes, there occurs a mismatch between the external customers and the students regarding their understanding of the requirements, which demonstrates that collaborative work requires a high degree of human interaction management, as well as management of project milestones.

D. Advantage of Collaborative Teaching: SS Course
Collaborative teaching is mostly beneficial as it provides a wider vision, taking student diversity and the dynamic nature of the course into consideration. Our previous experience in collaborative teaching shows that in some cases it may prove difficult: there may exist different visions since the focus varies. In that sense, it is easier to start and conduct a course on one's own since once others join in, they have to be guided, adjustments made, etc., which may sometimes negatively affect students and naturally takes time to yield positive results. In the case of the SS course, the added value of non-technical expertise of the co-instructor lies mainly in (inter)personal development, consultation about interaction with customers and customer relations (management aspects), as well as in support in the overall course management. This results in a more reliable course content, with mutual instructor consultations regarding decisions (and timing of decisions), and this course demands such decisions, e.g. about the ways of explaining certain constraints to customers, monitoring customers, the degree of intervention in students' decisions when, e.g., being aware that they are heading in the wrong direction. The question then is whether to let the students learn from their own mistakes or take over control of the situation by contacting the customer in question on their behalf in order to prevent mistakes or redress certain course of action. Such decisions are best taken collaboratively.

E. Advantage of Collaborative Teaching: SEIA Course
In this course, both instructors complement each other as they pay attention to different aspects of the course content and learning outcomes; they ask different types of questions, and their comments differ. In this way, various points of view are taken into account, alternative discussion points identified and verbalised. The instructors also employ differing styles of teaching, presenting information, involving students in interaction, and giving feedback. Consequently, students are exposed to alternatives and gain a broader picture of the software engineering field. They also have an opportunity to seek individual consultations and discuss respective assignments with both instructors. In class, technical exercises submitted by students are anonymously discussed, together with the prototypes and solutions suggested. In a follow-up step, students work on improvements that they can again discuss individually with the instructors.  Fig. 3 shows the overall average of the TA pre-and postassessments. 14 students were divided into 2 groups, and worked on different projects requested by real customers. The TA surveys were conducted both prior to taking the course and upon its completion to observe the behavioural characteristics of the students related to collaboration awareness. In Fig. 3, the highest average of all characteristics coincides with the adult stage that indicates any reality-bound adult-like behaviour as a response to here and now. At this stage students were considerate and respected others, and tried to gain clarity by means of, e.g., open discussions; but, on the other hand, they sometimes tended to use rational debate to achieve the right outcome and hence became critical. On the contrary, the lowest average was that of engaging behaviour from childhood that pays no attention to parent rules or limits. Moreover, there were no considerable differences observed when Adult (A) and Free Child (FC) were compared at the highest and lowest average points. show opposite results. It appears that the team course assignments made students realise the value of collaboration and looking after each other's interests as based on a genuine regard for the difference in ability and skill. Initially, they would rather passively imitate others or copy from the previous year's student assignments than show any initiative. As presented in Fig. 5, when we focus on both FC and AC, the pre-and post-assessment results do not exhibit any big differences, apart from AC behaving in such a way as to meet other students' expectations. This demonstrates that in order to work collaboratively, students tend to care for others. In the course of 3 months, students' collaboration made them behave and see others in a more professional way. The biggest challenges were peer interaction (due to differences in knowledge and skills), negotiating, and solving problems encountered in working with the real customers, who were, simultaneously, trying to find the best solutions, but from their (non-IT) perspective.

G. Student Self-Evaluation (Skills aquired in SS)
The final self-reflection took place after handing over the completed software product to the customer, and, on the whole, students claimed that they improved their overall project management, communication, presentation, writing, business, and software development skills (for self-evaluation breakdown, see Fig. 6).
Specifically, the following skills were self-reported as improved or newly acquired: • Presentation skills: presenting facts (previously very difficult), representing information visually, giving an overview of the project, presenting ad hoc (no 'speech script), explaining complex technical content in an easy to understand way, summarising information preserving the intended message, detecting what the other party wishes to know and meeting their expectations, explaining in a logical order; • Written skills: improving accuracy of expression, summarising, making presentation materials, clarifying ambiguity and reducing the possibility of misunderstanding, writing in non-technical language, in an easy to comprehend way, establishing sequential order of the written material to be presented, presenting facts in writing (difficult in the beginning -both in oral and written form); • Business skills: familiarity with the ChatWork task management tool, creating reports, business interaction, consulting skills, facilitating a meeting based on an agenda, managing meetings, note and minute taking, precise information retrieval and regular updates, assessing the weight of oral versus written information, chairing a meeting efficiently, reporting on tasks to team members; • Software development skills: understanding the processes and programming aspects of software development, familiarity with software development tools, e.g. Super Agile Struts (SAStruts), API mapping; reading programs written by others and understanding their structure, understanding customer needs (request proposal), program testing, web design, HTML, web system development tools -e.g. Seasar2, Ajax library, Java script, mathematical data analysis, and development of written documents.

H. Teamwork (Instructor Perspective)
The primary SS course objective is not team building per se, but understanding software development; teamwork is a tool not an objective in this case and functions as part of project management in software engineering. But as teamwork is required, students naturally build teams, more or less successfully, but some 'teams' do fail at teambuilding and teamwork. Nevertheless, they learn some valuable lessons in the process and those students who try hard acquire some teamwork related skills (see student self-reflections in Fig. 7).
The system of rotational leadership is applied so that the learning process is, to a certain degree, equal for everyone involved. Too frequent a change in team leadership is not desirable, however, as this may lead to the customers' confusion. Therefore, as a compromise, not all but a few (usually most motivated) students become leaders. On the other hand, a given team evaluation does not always depend on the leader (the leader in some cases may contribute the least). Students are taught team membership, assume different roles, and learn how to contribute to the team. The drawbacks include uneven distribution of tasks, disproportional contributions (with freeloaders taking credits for others' work), and the like, which makes individual assessment rather difficult.

I. Teamwork (Student Perspective)
The SS course participants' reflections regarding collaboration in teams are summarised in Fig. 7.

J. SS Course Benefit
As discussed above, students submit reports on what they have done as well as self-evaluation reports ("self-reflections") on personal development (acquired business skills, communicative skills, teamwork, management skills). Almost all participating students say that they have gained valuable skills, with some, more open, admitting that although the course is difficult, they have gained a great deal from it and, overall, it has been a rewarding experience (see Fig. 8 and Fig.  9). The SS course is embedded in the software engineering track; so it is mandatory to attend, but some students drop out. Naturally, it is easier to conduct the course when only the motivated students stay. But working with less motivated students makes the situation much more real. This is a unique realistic environment, comparable to a workplace, where one may not be inclined to work with certain people but has to do so. The course is taught in Japanese and the customers are Japanese. Although student are taught in their native language, they still need to learn to express themselves, identify and articulate problems (in a timely manner), and then -in graduate school -they move on to multicultural environment. In this sense, the course offers a good preparation for graduate courses. Students are capable of answering questions when asked directly. Internal understanding of the processes involved in software development is crucial at this stage, which they seem to acquire.

K. SEIA Course Benefits
Students in the Software Engineering for Internet Applications course become familiar with the soft (nontechnical) factors affecting the performance of software development teams, which include team climate, team diversity, team innovation, team member competencies and characteristics, top management support and team leader behaviour, which all have a considerable effect on software development team performance, also in pair programming.
Mutual trust and communication effectiveness are found to be the prioritised factors affecting software development teams' performance.
In this course, work in teams is, unfortunately, only theoretically discussed and based on case examples rather than hands-on experience (e.g. the concept of "two-pizza" teams in SaaS -software as service -and Scrum). This is due to the small number of participants and the short duration of the course (10 weeks), which makes team building a rather futile task.
One point made clear is that desirable software capabilities cannot be achieved without developers demonstrating those characteristics themselves. These include, among others, availability, correctness, reliability, integrity, efficiency, userorientation, flexibility, and creativity [8]; [9]. Students draw parallels between desirable software features and the skills required to create such software. They learn that communication in software engineering is multi-fold and complex, as many stakeholders are involved [10] (cf. Fig. 10). Change management as "the only constant in software development" is also discussed. It involves planned software requirements, bug fixes found during testing, correcting unanticipated consequences, and fixing customer complaints. Within IT, change control is a component of change management. The change control process is usually conducted as a sequence of steps proceeding from the submission of a change request. Typical IT change requests include addition of features to software applications, installation of patches and upgrades to network equipment.
In both courses students are exposed to negotiation (in SS hands-on; in SEIA more theoretically), which is a key skill in SE. Typically during negotiation, the software engineer reconciles conflicts between what the customer wants and what can be achieved given limited business resources. Requirements are ranked (i.e. prioritised) by customers, users, and other stakeholders. Risks associated with each requirement are identified and analysed. Rough guesses of development effort are made and used to assess the impact of each requirement on project cost and delivery time. Using an iterative approach, requirements are eliminated, combined and/or modified so that each party achieves some measure of satisfaction.
A mild critical feedback is given in class without pointing to a particular participant (taking the Japanese cultural factors into consideration). Students are also praised whenever possible to facilitate motivation (e.g. "You've done your best", "Great").
The technical instructor guides students toward optimised solutions from their points of view rather than imposing his own idea (e.g. regarding design). The questions typically asked include: "How would you improve your own solution?"; "What were the points of difficulty?"; "How long did a given task take?" "Was it interesting/difficult about working with the tool?"; or "What about applicability to multi-screens?" The key assessment of students' performance is carried out during the final project presentations (the task being creation of a Software Engineering Lab website). This is done individually; there is no teamwork involved, as previously mentioned. Each presentation is followed by a Q&A session.

III. CONCLUSION
Based on our investigative study and first-hand experience teaching the courses in question as non-technical instructors, we have observed that course participants clearly profit from collaborative learning: they become more confident and willing to communicate with others in complex business multi-channel situations (which otherwise poses a definite challenge to Japanese CS students), and may eventually reach the stage where they actually work productively as a team. Collaborative teaching makes it possible for students to gain a more complete picture of multi-fold characteristics of their tasks as future software developers and the expectations placed on them by various stakeholders. The instructors also profit in the process, for instance from sharing of ideas and materials, exposure to differing teaching styles, and peer feedback. We have also observed that technically minded students in our study tend to have difficulty comprehending and identifying the soft aspects of software development and the non-technical requirements of software engineering-related job positions, not to speak of fostering those skills in themselves. The same applies to the aesthetic aspects of software design. This leads us to conclude that such factors should also be incorporated in other engineering course syllabi and dealt with in detail.