Rolling: A new technique for the practical teaching in computer ...

Educ Inf Technol (2012) 17:49–77 DOI 10.1007/s10639-010-9144-6

Rolling: A new technique for the practical teaching in computer science university degree Irene Luque Ruiz & Miguel Ángel Gómez-Nieto

Published online: 26 October 2010 # Springer Science+Business Media, LLC 2010

Abstract In this paper we describe a new methodology for practical teaching in the Computer Science University Degree. The methodology is based on the Rolling technique. This technique consists in assign, in a rotary process, tasks, activities and responsibilities to students along an established calendar with the aim of developing a software product. Practical teaching is supported by a student-teacher contract that describes the goal, rules, plan with stages and activities, responsibilities and even the assessment method. Students are organized in groups and teams, emulating a company organization. They develop all the activities of the software engineering process in order to obtain a commercial product (the goal). In this process, students take different responsibilities over the software verification and validation, activities and tasks, and over groups and teams leadership. Along the teaching process, comprehensive information about the working team, time invested, deliverables in each stage, and work/students assessment is gathered. The methodology has been tested for 4 years at the University of Córdoba and the results, described in this paper, have shown an improvement in the students learning as well as in the acquisition of attitudes and skills mandatory for their professional development. Keywords EHEA . Rolling . Learning method . Collaborative work . Teamwork . Skills

1 Introduction The new teaching model deployed in the European Universities under the European High Education Area (EHEA) guidelines, originated in the Bologna Declaration I. Luque Ruiz (*) : M. Á. Gómez-Nieto Department of Computing and Numerical Analysis, University of Córdoba, Campus de Rabanales, Albert Einstein Building, 14071 Córdoba, Spain e-mail: [email protected] M. Á. Gómez-Nieto e-mail: [email protected]

50

Educ Inf Technol (2012) 17:49–77

(Council of Europe 1997), directs the development of university students mostly into the improvement of the skills that would later allow them to develop personally and professionally, instead of the classic model based on knowledge development. EHEA promotes a flexible model and an open framework that is properly described by the following teaching principles (ENQA 2003): (a) relevant cause learning, stimulating and guiding the student, actively involving students in their learning process while encouraging self-regulation, (b) appliance of the knowledge to everyday issues, settling this knowledge and enabling its transfer, (c) cooperative work among equals, (d) creation of face to face and virtual communication spaces, dynamic and friendly, (e) strengthen of the progressive intellectual development based on self-stimulation of critical and singular thinking, (f) evaluation understanding as a mean for regulating the teaching and learning processes. In order to implement the new teaching model, practical training of the students from the information technology (IT) degrees should involve not only learning to use new tools and software (languages, operating systems, communications, etc.) but also to be exhaustively trained on the process of developing new software solutions. The target is that a comprehensive education must be centered in the student learning to develop quality software and the “simulation” of this process, in the same way as this is carried out in real enterprises (Casey and Richardson 2009). This simulation assumes that the student would carry out his practical work taking into account, among others, the following aspects: tackling the solution of a new problem emerged during the course, providing a software solution to the proposed problem, carrying out work in groups, coordinating his work with other groups’, adjusting his work to standards and protocols, assuming responsibility for the work carried out, carrying out the monitoring, tracking and recording of the activities undertaken by each participant through the Configuration Management (Keyes 2004), capturing and recording the work load for subsequent studies on several aspects that would be developed by teachers, technicians, or so. The development of practical work under these circumstances would lead to a work more fitted to what the student would face in a company. Usually, the practical work that is programmed in certain subjects has as its main objective the development of different skills in the student and the improvement of the assimilation of theoretical concepts, losing the interest that students might have in the software development. They often perform this practical work repeatedly along the academic years, resulting in spoiled skills and time. Nowadays, software development teams commonly distribute the work among their members by following well-defined structures of interdependent responsibilities with typical assigned roles (Benarek et al. 2005). Due to this fact, researching in the development of new teaching models based on the collaborative work of the students is gaining interest, even more in Computer Sciences degrees (Johnston and Miles 2004; Muehlenbrock 2006; Wang 2009; Sancho-Thomas et al. 2009). The development of the teaching models based on the students’ team work is not a simple task (Smith 1995). Teamwork involves much more than working on a team, it really involves working in a variety of roles that team members might undertake (Slavin and Karweit 1985). These roles include, among others, leadership and vision, detailed planning, development of the technical work to be undertaken, as well as recording, documenting and reporting about the work achieved. Those skills are hard


51

to be taught; it is complicated to carry out a teaching planning suited for that purpose, because it requires an extra effort from the teacher and, the most important part, requires the student to be committed and available. Different authors (Meng-Hsiang et al. 2007; Hübscher-Younger and Narayananb 2003; Moreno et al. 2007; Russell and Goodnight 2009), in the last 10 years have studied, proposed models and carried out teaching experiences where it has been demonstrated that the teaching of future Computer Sciences professionals by making use of team working is appropriated for the development of the skills needed in those future professionals. In those investigations main elements to be taking into account are revealed and analyzed: (a) preparing and choosing of the work, goal or objective, (b) size and method for creating the groups, (c) tasks assignment, (d) surveillance of the activities, (e) responsibilities assignment, (f) follow-up, recording and controlling of activities, (g) work and students valuation, (h) motivation and conflicts resolution, (i) interdependencies and team coordination. Slavin (1988) and Bacon (2005) studies reveal that the team work is an efficient method for teaching in computer sciences degrees just if two basic conditions concur: (a) positive interdependence or “group goals” and (b) individual accountability. Russell and Goodnight (Russell and Goodnight 2009) describe the methods generally used in the teaching in Computer Sciences by the use of teams, regarding that the teaching of software development professionals was carried out based on the “trial and error” method, which is not appropriated for it. Authors describe some deficiencies as: (a) creation of teams based on personal affinity and not on mix of skills, (b) team work without a clear assignment of roles and responsibilities, (c) lack of recording of the activities and work of the team’s members, (d) no explicit development of teamwork skills or explicit reinforcement of teamwork skills learned elsewhere. In order to remove those inconvenient, Goldschmid (Goldschmid 1971) and later Russell and Goodnight (Goodnight et al. 2008; Russell and Goodnight 2009) and Coffield (Coffield and Edward 2009) propose a teaching model called “Rolling Learning Cell” based on the tasks and responsibilities rotation among the team members. This method is based on two stages. In the first one, four responsibilities roles are assigned to each team member: project coordinator, research analyst, implementer and writer, which rotate among the members. In the second stage, once the specification or even a prototype of the system is achieved, all the team members work together in all the responsibilities. The method described in this paper is based on these proposals, but introducing some main changes that improve considerably the teaching method, allowing a more comprehensive training of students. In our method different responsibility levels are established: –

On one hand, the groups in each stage or rotation process have assigned all the responsibilities corresponding to the different tasks related to the software development process (analysis, design, codification, etc.). Rotation is not done based on responsibility but on activity or component of the product to be developed. This allows: ○ In the different rotations, all the groups know the final objective, increasing commitment and motivation in students.

52


○ Simulations can be carried out with more complex products that require a greater effort from the students, but which are closer to the products that the students would develop in the future. ○ The responsibility is established over components of the product, allowing a better recording of the activities of the students. –

On the other hand, in each stage, activities (groups’ work) of acceptance, validation and sign off are established for the different deliverables. In these responsibilities all the team members are involved at different levels; they rotate along the stages and impact both product components and tasks carried out by the groups.

As would be described along the paper, our method proposes the rotation by components of the product, by responsibilities of the students in the activities of the process of software development and by the professional responsibilities of the software development teams. For that, a time planning of the process of the software development is done in stages, as well as an architectonic breaking down of the product so: – –

– –

The work could be developed over an initial specification and some established standards, although bounded to modifications that should be accepted by the working team. In each stage the groups of students are in charge of carrying out all the tasks of the software development process over a component or architectonic artifact of the product, generating a prototype. This component is subdued to acceptance, validation and sign off processes by other groups, this responsibility is assigned in a rotary way in each stage. Each component or software artifact is assigned to a new group in consecutive stages, creating an improved overview (a new version) of the prototype. Recording of the activities per student, group and team is done in each stage of the process.

The method proposed grants the teaching both in the knowledge needed by a Software Engineering professional and in the skills needed for team working, promoting responsibility, fellowship and leadership.

2 Materials, resources and method The development of the practical teaching model in Computer Sciences described in this paper has been carried out in the following way: 2.1 Time interval of the study The study was done during four academic years, from 2006–2007 (although not complete data were gathered) till 2009–2010, what has allowed us to obtain enough information to evaluate the results obtained.


53

2.2 Subject, course and degree The study has been done in the practical teaching of the Advanced Software Engineering subject. This subject is taught in the last quarter of the last year of the Master in Computer Sciences degree at the University of Córdoba (http://www.uco.es). This subject has a teaching load of 9.0 ECTS credits (European Commission of Education & Training 2009), divided into 4.5 credits in master classes and 4.5 credits in practical classes, what implies 6 weekly hours (3+3) of class for the students. Therefore, it sums a total of 190 h per course, where 90 are attending hours and 100 are personal work. This subject has been chosen for the study because of the following reasons: –

– –

–

The number of students enrolled in this subject is relatively small with respect to the number of students in previous courses. During the years the study has been done, the number of students enrolled in the subject has been in the range of 22 to 34. However, not all the students participated in the study due to their personal conditions; that avoided them to follow the subject daily. A greater number of students would have made difficult to perform the teaching activities and their follow up. The students have a solid training in basic and advanced subjects of Computer Sciences, which permits the performing of complex and professional activities. In the last course of the degree the students show a higher interest and motivation, which allow teachers to propose complex and professional activities that require an extra effort from the students, over the one needed to just pass the subject by using traditional teaching methods (exam, course work, etc.). Teachers know the student from previous courses, his weaknesses and strengths, skills, abilities and competencies, which allows a better development, follow up and valuation of the activities.

2.3 Teachers The teaching staff has been the same during all the years of the study. Two experienced teachers, with more than 30 years of teaching experience in the University are the ones in charge of the master and practical classes of the subject. These teachers teach in previous courses of the degree so they know the students before they enroll in the subject; as well, the students are familiar with the teaching methods and characteristics of these teachers. It is a decisive factor in the study described in this paper that the teaching staff has been exactly the same. Although the students change from course to course, the teachers keep the same method and its application over the different courses, so the results obtained can be compared. Due to the previous knowledge of the students, the teachers could choose and tailor the students profile to the characteristics of the works to be performed in the different academic years.

54


2.4 Resources In the development of the practical teaching of the subject all the computational, bibliographic, multimedia and technical resources available in the University of Cordoba are used, as well as those of the student’s. 2.4.1 Hardware A room with 40 personal computers is provided to the students. However, the students are also allowed to use their own personal computer. Besides, a server is set up for the development of the experience with the following functionality: –

– –

Maintenance of the different versions of the system that the students must build during the development of the practical teaching, including the code, documentation and incidences and time reports. This information is managed by a configuration management system installed on the server. Deployment, test and execution of the prototypes of the software product generated along the teaching period. Management of the distribution list that is used for the communications during the teaching period between teachers and students and among the students.

2.4.2 Software All the software developed must be of public domain or the University of Cordoba must have teaching licenses (i.e. Microsoft Office used for the documentation). Depending of the work or problem established in each academic course, the software used has been different. Through the 4 years, different programming languages have been used (Java, C, C++, pHp, etc.), also, different database management systems (Oracle, MySQL), content management systems as Joomla! (Joomla!2010), configuration management systems as GeCo (Luque et al. 2008), SVN (Collins-Sussman et al. 2004) and operating systems (Windows, Linux, Unix) has been exploited, as well as edition, graphic, drawing and others tools. 2.5 Teaching method The method developed in the teaching of the subject for the setting up of the Rolling technique is based on: 2.5.1 Course and teaching sessions distribution Theoretical and practical teaching of the subject is distributed along the course in this way: –

First 2 months concentrate almost all the master classes with the aim of improving the technical teaching of the students (in this and other subjects). A 70–30 schema is used, so there are 4 h of master classes and 2 h of practical classes weekly.


–

55

Last 2 months, the proportion is the inverse one: 30–70, which permits the complete development of the activities which are the base or the teaching model proposed.

2.5.2 Contract teacher-students The guideline or teaching project of a subject, within the frame of the new teaching model defined in the EHEA, implies a teacher-student contract bond where the scope and limits of the compromise are clearly defined, as well as the objectives, ways and tools used for it, the effort required by the student and the valuation mechanisms. In the University of Córdoba is a requirement that the guidelines of a subject must be published 3 months before the enrollment period of the students start, and those guidelines must be under an established standard. The guideline is the document that results from a set of questions posed to the teacher as: ¿how does he see the subject?, ¿what methodology is he going to use?, ¿how is he going to evaluate the students?. So, it’s a document that would answer questions as: ¿what to teach?, ¿where to teach?, ¿who to teach?, ¿how to teach?, ¿when to teach?, ¿what, how and when to evaluate?, ¿what specific measures regarding diversity would be taken?, and some other conditions referred to the context and that would be needed to be specified. Definitely, it is a document where the teacher would describe the objectives to answer the following questions: ¿what do I want to achieve?, ¿how am I going to achieve it?, and ¿what are the difficulties I would have to face?. Hence, the final objective searched by the teacher is to plan the means and procedures that would allow him to get the students closer to an expert level in a certain subject, providing the students with a language and formal procedures in the subject, but at the same time with the capability of being flexible to new situations where they would have to use intuitive and more practical methods to perform the analysis and solve the problem. In the teaching methodology described in this paper, the description of the teacher-student contract corresponding to the practical teaching of the subject is a wide document that includes the following sections: The students work problem. The goal In each academic course, one or several problems are proposed (software systems) to be carried out by the students. The number of problems or systems set out depends on the number of students enrolled, complexity of the problem and, therefore, size of work teams created. The problem is a technical specification where the requisites and objectives for the development of a professional software system are underlined. Along the study, several problems have been set out concerning: (a) a teaching Web portal oriented to guide and counsel new students in the university life, (b) a system for controlling, following up and evaluating the practical activities in the Computer Sciences subjects, (c) a system for the management and handling of professional and scientific information of research groups, (d) a Web portal for supporting the activities of university advisors, and (e) an ecosystem that offers location support, broadcasting and alarms for companies and people based on the use of mobile phones (Matas et al. 2009c).

56


The methodology and the course rules The teaching methodology followed in the development of the activity is described in the teacher-student contract. This teaching methodology includes the description of the model and teaching techniques used and would be extensively described in the following section. Besides, this document includes the standards and rules that will guide the teaching. Mainly, this document includes: – – –

–

The use of the Moodle teaching platform (Moodle 2010), as technological resource for broadcasting any teaching matter. The specification of the resources that would be used, previously described in the previous section. The specification of the standards that would be used along the teaching period. Those standards would include procedures, methods and generic Software Engineering standards (i.e. the use of use case and sequence diagrams for the specification of the functionality during the analysis stage, etc.) and owned standards adopted by the teachers (i.e., the use of pre-established formularies for the specification of issues, controlling and time recording, etc.). The rules that would guide the academic activity. These rules would include the following aspects: student behavior, class attendance, tutorials and meetings norms, etc.

Follow up and timing Together with the problem specification, a time planning for the activities to be carried out is described. In this planning, the stages, tasks and activities are set up, as well as the milestones or control points where verifications and valuation of the work performed would be done. It also includes the deliverables that must be done by the students for being evaluated. The subject object of study is taught in a quarter (15 weeks), being the planning made by weeks in a distribution that takes into account the relation of master/ practical classes established along the period (70–30/30–70). Therefore, this calendar is tied to any change happened during the course, because unforeseen events, and thus, calendar deviations, might happen. Any change to this plan must always be done under a teacher-students agreement. The students assessment The assessment is a complex process where all the conceptions of personal and academic teaching are revealed, and it is made based on the concepts and academic and personal issues considered during the evaluation. The new teaching model promoted by the EHEA makes necessary to review the traditional assessment methods, based on one or several tests where the students have to prove the level of knowledge developed during the course. Besides, the evaluation of the activities is even more complex. It is not enough to evaluate the knowledge and skills acquired by the students, but also it is necessary to assess their ability to cope with real life situations. Hence, it would be needed to advance the establishment of new assessment models that take into account issues such as: processes, other intellectual characteristics of students (critical analysis, ideas development, etc.). Those mechanisms would also take into account hardly quantifiable aspects such as attitude and


57

professional behavior, teamwork, availability, fellowship, concern for learning, encouragement, values and so on. Self-evaluation could be a tool, which, well used, could provide teachers with quality information, both for the evaluation process and for improving the teacher’s planning. During the development of the experience, self-evaluation is a tool that keeps the teachers updated about the development of the work, the skills and knowledge gained and so on. Also, if performed under teacher’s surveillance, selfevaluation could provide a view of the quality of the teaching method used. 2.5.3 Generation of groups and teams At the beginning of the course, the students are assigned to groups and different work teams are created based on the complexity and number of problems set up. Bacon (2005) has demonstrated that the work in teams made by two students is good for the development of skills and attitudes. However, a team of two is too small for the development of a practical teaching in Software Engineering and for the assignment of different responsibilities, so Russell and Goodnight (Russell and Goodnight 2009) propose the work teams to be made by four people. Our proposed model differentiates between the work teams that are in charge of the development of a software product and the groups of students that make elemental work units. While work groups are constituted by two students bounded by criteria such as social affinity (Del Soldato and Boulay 1996; Jones and Issroff 2005), proximity, etc.; work teams could be made by a non limited number of groups selected randomly or by teachers’ criteria, just like the way it happens in companies. Groups are made by two students and its composition is chosen by them. The reason is that through all the teaching period, groups work in the same activities, what requires a close relationship between the components of the group, which is favored by empathy, friendship, closeness or any other criteria chosen by the students. Several works (Issroff 1995; Inaba et al. 2000; Slavin 1990; Alfonseca et al. 2006; Michaelsen and Black 1994; Oakley et al. 2004) have shown the benefits of working with a friend in a collaborative setting when faced with a task that relies on the use of metacongnitive skills. Teams are made by 5 to 15 students, and its compositions are chosen randomly (by a draw) or by teachers’ criteria in order to: – –

Show a closer situation that the one faced in a future in the company they will work for; where people cannot choose the people they work with. Widen the contact, personal as well as professional, of the student with its mates, without the influence of the personal decision which can be very good for the development of attitudes and skills.

The team assignment provides students with a perspective of working in the target project. Teachers commonly group students according to two different criteria. Although the team grouping made based on students relationship and on teachers’ criteria or randomly have its pros and cons (Deibel 2005), as largely shown (Johnston and Miles 2004; Oakley et al. 2004) final result relies more on other aspects as: responsibilities assignment, issues resolution, students’ motivation, etc.

58


3 Rolling: A technique for the practical teaching in computer science Rolling is a technique that has been developed with the aim of simulating the future professional work of Computer Sciences students, while they are taught competencies. This technique promotes the development of attitudes and personal and professional skills on students. Rolling technique is based on three main ideas: responsibility, fellowship and leadership. Through the different stages that the work is planned, the groups have specific activities assigned (components or artifacts from the product) with the objective of generating the established deliverables. Those deliverables: –

–

–

Are received by other group in the following stage, and the new group will continue with its development in this new iteration. The group that receives the deliverable in the new stage is responsible for validating that deliverable before the stage is finished. Are received by other groups on the team in the same and the next stage, due to the relationship among activities. Groups with extra responsibility (control groups) are responsible for giving the sign-off to those deliverables before the stage is finished. Are evaluated by the teachers who accept or reject the sign-off.

As all the groups are responsible for validating the deliverable of other group, the executing students (those who perform the activity) and the reviewers (those who validate the activity) acquire good work practices, assuming responsibility for the work undertaken. This happens because students are the ones that evaluate the deliverables that they will receive for performing their work in the next stage; while at the same time, they are evaluated by the group that will receive their work in the next stage. As shown in Fig. 1, Rolling technique makes possible that during the teaching activity, all the groups could play different responsibility roles over several professional sides of the software development process. This approval-validation–accept flow that happens for every activity in the different stages promotes the team building attitude among the students. And not only among the students in the same group, who have to work in a collaborative way, but also among all the students that realize they must work together to reach a final and common objective. As there are dependencies among activities in the same stage and, clearly, the deliverables in a stage are the inputs for the following stage, the problems of a group impact all the other groups, so a natural collaboration appears and the students improve their learning notably. This collaboration stresses the leadership attitudes and capabilities in students, demonstrating their organization, managing and supporting capabilities; taking decisions that impact not only their own group but also others. Those attitudes are spread to other students, so a more effective work environment appears naturally. During the 4 years the technique has been tested, very few problems referred to groups/students that haven’t acquired those capabilities have arisen. The method has allowed teachers to see those issues in an early stage of the teaching period so they were quickly and neatly solved.


59

Fig. 1 General view of the Rolling technique

3.1 Rolling technique foundations The method developed while teaching the subject for the use of the Rolling technique is based on the components shown in Fig. 1. The objective of practical teaching is the development of a software system emulating, as much as possible, the professional activity that students would have to develop in the companies they will work for in the future. For that, the spiral paradigm is proposed as the development model, so, in the following stages the teaching is organized (and also in the process of developing the product) different versions of the final software are obtained. In each stage, the students, depending of the activity assigned, would have to carry out different tasks: specification, analysis, design, programming and testing of the assigned component or components of the software product. The schedule or working plan for the course is structured in stages. Each stage is made by activities, oriented to different components or subsystems of the final product, so the activities are repeated along the stages, although some activities could disappear, and new ones could appear along the schedule. For example, an activity in charge of the design and building of the database would appear at the first stages, disappearing once the database design is validated, and, in the system testing stage an activity related with the fine tuning of the database could appear. In the same way, an activity in charge of building the on-line help procedures would only appear in the last stages of the project. Students enrolled in the subject are organized as aforementioned, by groups of two members chosen by the students, and afterwards, those groups are organized in teams which are assigned different problems or different modules of the same problem. At last, the technique described in this paper is based in the way the activities are assigned to the groups in the different stages. As shown in Fig. 1, groups rotate through the different activities along the stages, so, at the end of the schedule, each group has worked in almost all the different activities or components of the system

60


under construction. Despite the fact that this technique would warrant an appropriate knowledge level of the students in the professional development of software products; the technique is not sufficient on its own, and other characteristics are introduced as follows: 3.1.1 Responsibility assignment During the teaching process, in the different stages, groups are assigned different responsibility roles. A responsibility role implies an extra work for the group. Roles are: – – –

Approval role: the students (group) have the responsibility of approving or not the deliverable corresponding to the work done by other group. Validation role: the students (group) have the responsibility of validating or not the deliverable (previously approved) corresponding to the work performed by other groups (one or many). Configuration management role: the students (group) have the responsibility of accepting as an element of the configuration (part of the prototype) the deliverable (previously validated) corresponding to the work done by all the groups.

An important aspect of the technique proposed is the assignment of: who do, what group, approve the deliverable of other group? The technique used again a rotatory assignment of responsibilities for deliverables approval, so the group in charge of approving the deliverable of an activity in a stage is the one that would have that activity in the following stage. An example can be seen in Fig. 1, where an example of the Rolling for 3 stages, 5 activities and 5 groups is shown. In stage 1, G1 has the A activity assigned, the group in charge of approving the deliverable is G2, who would hold the A activity in the following stage. In stage 1, G2 has the B activity assigned, being G3 the one in charge of approving the deliverable and to be in charge of activity B in the next iteration; and so on with all the groups, activities and stages as shown in Fig. 1. By this Rolling process several teaching objectives are achieved in the approval of the deliverables from the different activities in the stages of the project: 1. Students go through learning different components, elements, subproducts, etc. of the programming product, performing all the tasks of the development paradigm chosen. 2. Students must assure the use of the development standards chosen, performing their work and generating their deliverables (code and documentation) as per those standards and also following Software Engineering’s good practices. 3. Students responsibility is motivated by three main aspects: a. Students must approve or not the work performed by other students, knowing that those work would be their information source for the work they would perform in the following stage (i.e., G2 approves the work of G1 done over activity A in stage 1; in stage 2, G2 would use that work as source for performing the next iteration of activity A).


61

b. Students must perform a professional work because their results would be reviewed in order to be signed off, and their future work would depend on the work of other group, approved or not by themselves. c. Both the approval and the denial of a deliverable must be done based on a rationale, through the use and recording of the corresponding issue documents. Those documents could be refuted and are always reviewed by the teachers who, as last resource, would take a decision on the matter. The official formalization of an approval or denial of a deliverable increases the motivation and responsibility of the students. 4. Fellowship is incentivated because groups which work requires the approval of other groups would start naturally to collaborate among them in order to create professional deliverables. Apart from that, the issue documents for the approval are oriented to “positive” aspects, supporting and helping other students for performing their work. Therefore the sense of a “common objective” that, for its fulfillment, requires everyone’s collaboration to arise naturally. The validation responsibility plays a very important role from the point of view of increasing the learning in attitudes and skills, more than in knowledge. For that, in each stage, different groups are chosen and assigned the validation responsibility. This responsibility, again, rotates through the different groups of students along the stages. The validation responsibility is assigned based on the product’s architecture, so the responsibility is assigned for: –

–

–

–

Design, ergonomics and usability: the group is responsible for validating the fulfillment of the standards accepted for the design, ergonomics and usability of the system. Besides, this group is responsible for establishing new standards and patterns that must be followed on all the components of the developed system in the different activities. Tools, code and good practices: This group is responsible for the fulfillment of standards and codification and software development tools, as well as for validating the use of programming good practices referring to style and quality of the code created. This group is responsible for establishing naming patterns for variables, methods, packages, etc., as well as for establishing the tools needed for the development of the different components of the system. Documentation, auto documentation and styles: this group is responsible for the fulfillment of documentation standards and for validating its completeness for the deliverables of the different activities. Besides, this group is the responsible for establishing new documentation standards, patterns and styles that must be followed by all groups. Integration and management: this group is the responsible for the integration of the components performed in the different activities of each stage in a sole prototype, able to be tested and evaluated. Deliverables must adjust to the standards established by the group in shape and content so the integration of the different modules or components of the system could be performed.

Finally, in each stage a group is designed to be responsible for the Configuration Management. This group has the responsibility for carrying out the management of

62


the product configuration in its different aspects along each stage, and, therefore, for accepting the different components of the product, once validated by the other responsibility groups, as the configuration management element. Among its responsibilities are: maintenance of the system or tool used to carry out automatically the configuration management, establishing rules for working and operations, product version management, issues and documentation maintenance and acceptance of the deliverables once validated by the responsibility groups. The establishment of those responsibility groups has as objective to achieve different teaching objectives. On one side, the objective is to support those abilities developed by the Rolling technique, achieving an emulation of the professional activity of the engineering process, favoring the professional good practices, the sense of responsibility and increasing fellowship among students. Besides, the assignment of the responsibility groups in a rotatory way along the stages denotes naturally some leadership abilities among students. In this practice, students accept, more or less, the decisions taken by the groups that validate the deliverable previously accepted, revealing the groups accepted as leaders by others and which groups assume the leadership role naturally, proposing rules accepted by all the other groups. 3.1.2 Flow of information and materials The tasks assigned to each group in the different stages are perfectly described in the activity assigned to each group. Those tasks must be performed in the dates established in each stage, although the calendar could be modified due to incidents happened during the course. During the development of those tasks, a set of flows of information and material appear, which are supported by the configuration management system used and by other teaching resources as a private mailing list, created for the communication among teachers and students, and also only among the students. Figure 2 shows a scenario for the information and material flow for a stage. Initially a group takes care of the component corresponding to the activity assigned to that group. In this process, and depending of the stage, different tasks of the Software Engineering process would be carried out (specification, analysis, design, programming, etc.). Once the development is finished, the corresponding deliverable is downloaded into the repository of the configuration management system. That download is done in a temporary download area assigned to each stage in the repository. For each deliverable downloaded into the repository, a message is sent to all groups for their awareness. Further, the group in charge of approving the deliverable (which would be the group that would continue with that activity in the following stage as shown in Fig. 1) picks it up for its scrutiny. As a result, an issue document is generated, downloaded into the repository and broadcasted to all groups. Therefore, two situations could take place: – –

The deliverable performed by the working group is accepted. The deliverable is not accepted. Herewith, what is not accepted and why is not accepted is specified in the new issue document, as well as what and how must


63

Fig. 2 A scenario of the material and information flow

be corrected, together with a solution or correction proposal. In this case, two scenarios could follow: ○ The group accepts the issue resolution and starts its correction. ○ The group does not accept the resolution, so both groups and the teachers decide the solution that fits them all. This process can take place as many times as needed (experience demonstrate that it rarely happens more than twice) till the deliverable is accepted. Once the deliverable is approved, the temporary version stored in the repository is gathered for its study by the different validation groups as described previously. All the validation groups are subdued to the study of the deliverable approved, independently of whether its responsibility impacts or not the component of the software product corresponding to the deliverable. The described process for the approval is repeated for its validation. The different validation groups generate an issue document that is downloaded into the repository with the corresponding and justified approval or denial, in the last scenario, the group has to proceed to its correction. Once the deliverable is validated by all the responsibility groups the work of the group responsible of the configuration management starts. This group takes the elements of the product from the temporary repository and accepts them as configuration elements of a validated version of the prototype. In this moment the version (the stage) is closed and a new iteration and rotation is established for the new stage.

64


During this process, a new version of the prototype has been generated, as well as a new version of the documentation and a set of documents corresponding to the issues that have happened along the process. Besides, other documents with a high teaching utility for the teachers have been generated: the documents about the student’s work load. Once all the deliverables are validated, each group must complete a form where they specify, in different sections, the time or effort invested by each student of the group in the development of the activity. In this document the tasks of the development process are detailed: specification, analysis, design, etc., as well as the tasks related with the meetings among groups and with the teachers (including the classes’ hours, tutorials, formal technical meetings, etc.) and even the time invested in commuting or reviewing for approval and validation tasks. The information received by the teachers along the teaching process is quite valuable, because apart that the fact that the measures show clear deviations among the “subjective” measures of the times made by the students in the different sections compared to the expected and to the times of other students/groups, the following could be obtained: –

–

–

A measure quite close to the real effort assumed by the students in the development of the different tasks of the engineering process. This measure allows the teacher to update the work of the students for a better fitting to the desired professional work. Measures that allow to correlate those timings with other results of the evaluation/questionnaires that the students do at the end of the course, noticing, as will be described later, a relationship between responsibility and leadership attitudes and the student’s effort. The effort or total time invested by the students in the development of the course work, obtaining measures of the deviations regarding the real work load that must be assumed by the students (number of credits of the subject). This allows the teachers to improve the established planning along the current course and for the next ones, and also to fine tune the complexity of the problem, the activities assignment, the size of the teams, etc.

4 Experimental results and method evaluation During the experience, in each academic year, the gathering of a set of records corresponding to the effort (time invested) by the students in the activities performed has been carried out. Besides, at the end of the course some surveys are done to the student which aim is to: – – –

Perform the student’s self-assessment in the development of the activities. Evaluate the students under other student’s view, both the group and team mate, and in case some groups collaborated together in the development of a problem, those would also be evaluated. Evaluate the teaching method and technique as well as the teachers.


65

The results obtained allow us to obtain metrics enough for evaluating the teaching method by different points of view that would be exposed as follows: 4.1 Course teaching plan and student effort The Advanced Software Engineering subject used in this study has, approximately, 190 work hours for the students, which split as follows: (a) 30 h for master classes, (b) 30 h for practical teaching, (c) 30 h for other facing activities, and (d) 100 non facing work hours for the student. Planning is organized so near the 80% of the non facing activities are dedicated to the practical activity. So, together with the teaching facing hours, about 140 h is the effort that the student would have to do in order to finish the assigned tasks. Teachers’ planning must take into account this time in order to prepare the problem that would be developed by the students and how the activities would be distributed along the course so the student can have time for the master classes given, nearly all, in the first 2 months of the quarter. An example of the results obtained for the experience in the 2008–2009 course is shown in Fig. 3. In this course two teams were made, with five groups each. Each team was in charge of developing an independent subsystem that provided a solution for the same problem. This problem was the development of a pervasive game (Seek-it & Touch-it) (Castro-Garrido et al. 2010) that was based in the location of objectives in an open environment and the resolution of teaching questions in order to achieve the prizes hidden in the objectives. All of this had to be done making use of the NFC (Near Field Communication) Technology (NFC-Forum 2010; Matas et al. 2010) and mobile phones, and it was also mandatory for the software to be Phase 1

Phase 2

Phase 3

Total 2500

Time (hours)

300

Time (hours)

250 200 150

2000 1500 1000 500

100

0

50

Phase 1 140,75

Team 1

0 T1G1 T1G2 T1G3 T1G4 T1G5 T2G1 T2G2 T2G3 T2G4 T2G5

Phase 2 359,75

Phase 3 529,5

Total 1030

Team 2

177,5

372,5

539,5

1089,5

All students

318,25

732,25

1069

2119,5

Groups

(a) Phase 2

(b) Phase 3

16

Total

160

14

140

12 Time (hours)

Time (hours)

Phase 1

120 100 80 60

10 8 6 4

40

Phase 3 33%

Phase 1 16%

Phase 2 51%

2

20 0

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

Students

Students

(c)

(d)

Fig. 3 Time invested by the students during the 2008–09 course: a time (hours) by groups and stages, b cumulative time by teams and stages, c time by students in different stages, d time invested in meetings

66


integrated with the Moodle system (Moodle 2010). Team 1 was in charge of the development of a Web portal for the (parametrized) generation of the different game sessions, and Team 2 was in charge of developing a Java system for the real-time follow up of the game evolution and results from any place through the access to the records generated in real time as per the players interactions, thanks to the use of NFC-GPRS. As can be seen in Fig. 3a, the work load of the problems set to the different teams was well distributed both in the total effort and in the effort made by stages. Students do a progressive effort along the course, being the effort smaller during the first stage and increased for stage 2 (the planning was done in three stages for the two teams). As in the first stage the teaching load of the subject is mainly invested in master classes (even thought the activity has started), the planning of the effort is, and must be, less for the practical activity. As the quarter is going by, the effort needed for the practical activity increases, being the total amount of the teaching load in the last months of the quarter the one shown in the stage three. Measures obtained are notified by the students for different tasks: – –

–

Tasks related directly with the software development process: problem analysis, problem design, codification, test and debugging. Tasks in charge of the work review and validation, development support, problem resolution, etc.: meetings among students of the same group, meetings among the students of the team or among teams and also meetings with the teachers. Other tasks where the students use their time: study needed for knowing the problem, technology, tools, etc., time invested in the commuting for meetings and facing activities, and also time invested in the communication through the mailing list, use of the configuration management system, etc.

It can be noted in Fig. 3a that the groups invest a total effort quite similar in the range of 180–245 h for the students in Team 1, and of 150–263 for the students in Team 2. This effort fits the teaching load in the subject, because it has a total effort estimated for the practical activity of around 140 h, bearing in mind that: (a) a part of the time invested is measured for “extra” activities not considered in the programming and teaching load of the subject, and (b) students tend to increase notably the numbers of hours accounted. In Fig. 3b the proper distribution of the work load assigned to both teams can be observed, which present a quite similar effort in all the stages. Team 2 shows values a little higher than Team 1 due to the fact that the problem assigned to Team 2 included a bit more technical complexity than the problem assigned to Team 1. In Fig. 3c the effort invested by the students in each stage and the total amount is shown (students 1 and 2 correspond to Group 1 of Team 1 —T1G1—, students 3 and 4 correspond to T1G2, and so on). Although the communication of the timings was done by the students, that information is provided by the team, and therefore, verified by the group mate and by all the other team members. This verification could provide an extra shade of veracity to the information, always bearing in mind that this information is provided by the students.


67

Timings shown in Fig. 3c contributes with information about several aspects: (a) effort distribution among the members of the same group in the different stages, (b) fellowship between the members of a group, and (c) other attitudes as responsibility and leadership of the students in a team as will be described later in the paper. It can be noticed that, while in some groups the effort is compensated between the two students, in other groups, one of the students perform an effort notably higher in all the stages. This positive attitude is lately checked with the evaluation that the team members give themselves, outlining that there are leadership roles among the members of the group. Furthermore, it is observed that in both teams there are groups that do a lower effort (i.e., students 7 and 8 from T1G4 group, students 11 and 12 from T2G1 and students 13 and 14 from T2G2), which could be due to a smaller complexity of their tasks in each stage due to the rotation technique, or just because they have done less effort, in this situation students’ evaluation about those groups would clarify the case, as will be seen later. Finally, Fig. 3d shows the time invested by each student in the verification and validation tasks in each stage. This figure provides extra information to the results of Fig. 3c. As can be remarked, the students that invested a smaller effort are the same that did not participate in verification and validation meetings, showing a lower participation in team’s activities, at least one of the members of the group. The absence in these activities implies a worst work planning and a higher effort to be made by the students in other group in the following stage due to the rotatory character of the activities. It can also be detected in Fig. 3d how the time invested in meetings is distributed along the stages. In Stage 1, only a 16% of the total time is invested as this stage takes place at the beginning of the course, where the master classes are the core of the subject and just some preliminary tasks of the product development are performed. Stage 2 is the one that takes more time for meetings (51%), due to the fact that this stage is where the core elements of the product are decided, so, it requires a higher number of meetings. The meetings time decreases as the product is reaching its final version (Stage 3) as the works are perfectly defined and standards are well assigned. 4.2 Application and learning of the software engineering process An important aspect of applying the Rolling technique is that the students have to face the different tasks of the software development process along the stages so, in each stage, the students develop more or less those tasks depending on the development status of the component and the kind of activity assigned. Along the teaching process, the students must complete recordings of the time consumed in each stage in the development of some tasks, as has been described in the previous section. In Fig. 4, information for the 2007–2008 course is shown. In this course there were two teams, made by five groups, which were assigned two problems completely different and without any relationship, although with a similar complexity: (a) a Web Portal for helping university new entrants (Matas et al. 2009a) for Team 1, and (b) a Web Portal for supporting and managing the activities of students’ assistance teachers for Team 2 (Matas et al. 2009b).

68

Educ Inf Technol (2012) 17:49–77 3% 4%

5%

4%

6%

16%

9%

5%

4% 3% 3% 4%

5%

6% 9%

31%

15%

9%

22%

11%

17%

Total time = 1.110,5 hours Study

Analysis

Design

Programming

Study

Analysis

Design

Programming

Test

Depuration

Documentation

FTR

Test

Depuration

Documentation

FTR

VTR

Commutement

Communications

VTR

Commutement

Communications

(a)

(b)

180

Communications

160

Commutement

120 100 80 60 40 20 0

Communications Commutement

100

VTR

20 23

FTR

50 52

120

8

8

30 30

Documentation

Depuration

10 10 39 10 45 42 10 40 35 35 2 2 30 30 20 3 20 1,5 3 1,5 3 3 1 2 3 4 5 6 7 8 9 10

Test

Students of Team 1

Study

(c)

Programming Design Analysis

VTR

Time (hours)

140

Time (hours)

9%

Total time = 813,0 hours

7 5

80

7 6 24

60

10

40

5 8

16

0

Depuration 22

6 6 10 10

38 12 38 15 15 3

5 3

1

Documentation

8

24 55 14 17 54

20

FTR

5 14

2

3

4

5

6

7

8

Students of Team 2

9

10

Test

Programming Design Analysis Study

(d)

Fig. 4 Time invested by the students of the 2007–08 course in the different activities of the development process of the practical activity

As can be seen in Fig. 4, even when the effort made by the two teams is remarkably different, its allocation to each activity is quite similar. As the problem is given to the students completely defined by the teachers, with a formal specification that includes the requirements specification and a preliminary analysis, students do not invest much effort in those stages of the software development process, spending between a 3% and a 5% of the total effort. However, the quality of those activities impact directly in the time invested in the codification, testing and debugging tasks. It can be seen that Team 2 dedicates a 31% of the total time in programming, while Team 1 just a 16%. While Team 2 dedicates pretty less hours than Team 1 (813.0 against 1110.5), Team 2 spend much more hours on programming (252 against 152) remarking the importance of the quality of previous activities. The time dedicated to documentation must be highlighted. The importance of this activity is normally misunderstood by the students; however, this activity is quite important in the software development and vital when applying the Rolling technique. As in each stage the groups must continue with an activity previously performed by other group in the previous stage, the documentation of the deliverables is vital for understanding the prototype or version delivered. This importance is well understood by Team 1 that allocates a 22% of the total effort (245 h) to this activity but not by Team 2 that allocates only a 15% (122 h) of the total effort to this activity. The difference between both percentages cannot be assumed even when the fact that the problems are different is considered.


69

The recording of the timings for all the tasks also brings out the importance of considering, by the teachers, the time needed for other activities not directly related with the teaching side, but that consumes time and effort from the students. As can be appreciated in Fig. 4, between a 20 and a 25% of the time that the student invest in the work, is allocated to activities as meetings, communication and commuting. In this figure the detail of the time invested for the different tasks in the development of the problem is also shown, including results for Team 1 (Fig. 4c) and Team 2 (Fig. 4d). As the groups have had assigned the same activities in the different stages, in this figure the distribution and work load of the components of each group can be inferred. From that, it can be seen that the distribution is more homogeneous for the groups in Team 1 than in Team 2. Data for Team 1 shows that the students from the group have worked collaboratively in each task of the process, close to behave as one element. In Team 2, there are groups where the times for the same task are quite different, outlining a bad understanding of team working, fellowship and responsibility in the development of the activity. Besides, it can be seen that the distribution of the time by tasks in those areas that are allocated a higher percentage (programming, debugging and documenting) shown in Fig. 4a and b, are not distributed in a homogeneous way between some groups of the same team. In the groups of Team 1 that have this difference (group 2: students 3 and 4 and group 5: students 9 and 10) the total time distribution is compensated, so it leads us to think that fellowship and leadership attitudes moved the student to deal a homogeneous distribution of the total work. However, this fact does not apply to Team 2, as can be seen for example for group 1 (students 1 and 2) what leads us to think in a team work issue. 4.3 Responsibility, leadership and fellowship Time records made by the students for the different tasks along the stages of the process allow teachers to notice attitudes and skills in the students facing the teaching process and the environment where it takes place. During the years that the technique underlined in this paper has been used, it has always been observed that 1 or 2 groups in each team, or particular students, assume a responsibility attitude which aim is to improve the development of the work assigned, in order to pass it obtaining a positive valuation. Responsibility brings along, generally, a leadership inborn in the groups/students, taking the job of setting up internal procedures (normally hidden to the teachers) that improve the organization and development of the work. Although some times is quite easy to teachers to see the students that have that skills inborn, other times that information keeps hidden in students that do not participate in class, being discovered with the information gathered. For example, group 1 from Team 1 (students 1 and 2) shows in Fig. 4c that it made a remarkably higher effort compared to the other students. This group assumed the leadership of the team, giving an example of how the work must be done and performing a higher effort. However, this attitude is not seen in any group from Team 2, but it can be seen in some individuals, strengthening the idea of a worst fellowship.

70


Those attitudes (and others) could be confirmed or discovered by the analysis of the information shown in Fig. 5. Once the teaching period has finished, the following events take place: –

The delivery of the work performed by each team, and consisting of the technical and user documentation, code, system (prototype) installed and executable, and the documentation corresponding to the configuration management (issues, timing control, etc.). An informal meeting with the students takes place, where the process is discussed, as well as any issue or problem related with the activity performed. Finally, a survey is performed; where the students must self evaluate themselves (between 1 and 10), its group mate and other team mates. In this survey the following is evaluated:

– –

○

Knowledge

Fellowship

Teamwork

Knowledge

Fellowship

Teamwork

Professionalism

Dedication

Availability

Professionalism

Dedication

Availability

10

Standard deviation

Students assesment

Knowledge: the level of knowledge with regards to the process of developing professional software products. ○ Fellowship: ability for supporting and helpings their mates in reaching their objectives. ○ Team working: the ability of working in teams, accepting and proposing ideas and directives from other members. ○ Professionalism: ability of performing a professional work that can be easily comprehended by its mate or inherited by other group and that meets the established standards.

8 6 4 2 0

2,5 2 1,5 1 0,5 0

1

2

3

4

5

6

7

8

9

1

10

2

3

Students of Team 1

4

(a)

6

7

8

9

10

(b)

Knowledge

Fellowship

Teamwork

Knowledge

Fellowship

Teamwork

Professionalism

Dedication

Availability

Professionalism

Dedication

Availability

10

Standard deviation

Students assesment

5

Students of Team 1

8 6 4 2 0

2,5 2 1,5 1 0,5 0

1

2

3

4

5

6

7

8

9

10

1

2

3

4

5

6

7

Students of Team 2

Students of Team 2

(c)

(d)

Fig. 5 Self-evaluation of the students from course 2007–2008

8

9

10


71

○ Dedication: ability of being involved in the work further than the minimum to pass it. ○ Availability: ability of being available for their mates for the developing of the work. Information shown in Fig. 5a supports the attitudes observed before for Team 1. Students from Team 1 valuate very favorably all the skills of their mates, group and team, being a little higher for the students in group 1 (students 1 and 2) who showed a higher involvement, responsibility and leadership than the team. Figure 5b shows the standard deviation of those reviews. As can be seen in the figure, there are students that have notably higher deviations because they have evaluated themselves more positively than the average of their mates’ evaluation. Reviewing the standard deviation allow us to amend the “false fellowship” attitude or the “over selfevaluation” one, which happens with students 4 and 9 from Team 1. Team 2 results, shown in Fig. 5c and d, corroborate the notes previously analyzed and discussed. Students’ valuations are remarkably lower than Team 1’s and standard deviations are quite higher. Students, as the number 7, have a very low valuation from its mates and a higher deviation due to a very positive self and group mate’s valuations. In this team, fellowship issues raised (as can be observed, for example, in student 7, and is a lesser extent in students 1, 3, 4 and 6), denying natural leadership, what led to a bad planning of the work and a low responsibility about its performance. Student’s valuation of the knowledge and professionalism items could be use mainly for noticing those leadership attitudes. If we analyze the results in Figs. 4c and 5a, it can be inferred that students 1 and 2 from Team 1 were the one that invested more time in product development activities (Fig. 4c), and that that work was largely acknowledged by their mates, that evaluated positively their knowledge and professional attitude for reaching the final objective. Other students with a lower result in knowledge, although high, were very positively valuated in professionalism (students 5, 6 and 10 from Team 1), noticing in Fig. 4c that those students were the ones that invested the higher effort in the deliverables’ final documentation. Again, their mates acknowledged their professional attitude in getting the final product. However, the acknowledgement of those attitudes is not so clearly defined in Team 2, as described previously. Results obtained by both teams corroborate again the information described. As Team 1 built a professional application (Tips & Talks, http://www.uco.es/iscbd/tipstalks) fully operative, Team 2 didn’t reach a final (and without errors) prototype, finishing with serious codification and design issues. 4.4 Teamwork and valuable student effort Students’ valuation of the items Teamwork, Dedication and Availability is a measure of the effort acknowledged for their mates and their ability of working in a team, helping and collaborating in carrying out the tasks assigned to other members of the group and team. Those measures also allow teachers to “weight” the times measures by the students, allowing them to find deviations between the time noted by a student (regarding the time invested in his work) and the time noted by his mates.

72


Team 1’s observations corroborate again all the assessment made previously for the Group 1 (students 1 and 2) who show a high valuation on those items. In Team 2, valuation of those items is notably higher for students 2 and 5 as can be seen in Fig. 4d who were the ones that noted a higher working time. Despite the scarce fellowship observed, members of the team admitted the labor of those two students, their dedication and team working abilities. Other students that noted an effort over the average (students 3 and 4 from Team 2, see Fig. 4d) weren’t positively valuated on those items, which indicates that those times were over estimated, or at least, were not noticed by the other mates. However, students that noted a work time notably lower than the average (students 9 and 10) were quite well valuated on those items. Teachers observed during the teaching period the professionalism and dedication of those students, which led them to report real times, resulting in lower marks than their other mates in Team 2. 4.5 Learning technique assessment Students’ opinion about the technique for practical teaching is obtained through a questionnaire answered by the students that participated in the experience and that is made at the end of the teaching period. The questionnaire is made by five questions that the students have to valuate between 1 and 10 points. Questions are related with: –

–

–

–

– –

Technique used for teaching the professional development of software products based on the activities rotation, team working, work validation by other mates, responsibility and all those aspects of the Rolling technique described previously. Methodology used in the subject, in general, and in the practical teaching particularly, considering the planning (guide) in the subject, the calendar distribution between master and practical classes, tasks distribution in a calendar fully planed and distributed in stages and activities, the information recording, issues and timings, the use of configuration management systems for the version controlling, use of communication media, etc. Learning or knowledge obtained by the students thanks to the use of the methodology and technique in the teaching activity, considering its value in the context of the comparison against the classic teaching model followed in most of the subjects of the degree. Quality and Innovation of the teaching model and technique used. Valuating its correctness and complexity in the development of the activity and the teaching and technologic innovation gained with the process and techniques and tools used. Valuation with regards to the students’ view about its future application in their professional activity, as well as professional, teaching and personal advantages provided by this model. Utility, within a general view of the advantages of this teaching model for their learning and future professional activity. Overall Satisfaction of the activity performed, where the student could consider the aspects previously considered as well as any personal consideration.


73

Figure 6 shows the results obtained for the 2008–2009 course, detailed by student, that can be used not only to evaluated the quality of the Rolling technique, but also for gathering extra information to the data on Fig. 4, previously analyzed. As can be seen in Fig. 6, only 9 from the 10 students in each team made the survey (as its fulfillment is voluntary and not anonymous). Valuations from Team 1 (Fig. 6a) are notably higher than the ones from Team 2 (Fig. 6c), besides, standard deviations from Team 1 (Fig. 6b) are lower than Team 2’s (Fig. 6d). In Team 1, the best valuation is obtained for the quality of the technique used in the student’s teaching. Students considered that the model used fits them, what is mapped into a very positive global satisfaction valuation. The worst valuated item is the Methodology; the rationale given by the students is that this methodology implies an extra effort, much higher than for other subjects. This effort is due to the fact that apart from performing the task assigned in each stage, they must assume the responsibility of reviewing and overviewing other tasks, which lead them to an extra effort. However, they outlined that the rotatory technique, based in the responsibility and team working is a good choice, valuating this item quite positively. It can be observed that student 8 from Team 1, did not do the survey. If we go to Fig. 3c, we can see that this is the same student that invested less effort in the development of the tasks assigned in each stage, who, together with his group mate (Group T1G4) were the ones that performed the lowest effort. Valuations from student 9 from Team 1, lower than the average, cannot be easily understood, unless we analyze the valuations he received from its mates regarding the items described in Fig. 4, which were lower than his team’s. In Team 2, the lowest valuations for all the items were given by student 1, and student 2 did not do the survey. If we go to Fig. 4a, and c, it can be seen, again, that Average

Technique

Methodology

Learning

Quality and Innovation

Utility

Overall satisfaction

10

Standard deviation

9,4

1,6

9,2

1,2

9,0

0,8

8,8

0 1

2

3

4

5

6

7

8

9

0,0

10

Students of Team 1

(a)

(b)

Technique

Methodology

Learning


Utility


Average

10


2

0,4 Utility

8,4 Quality and Innovation

4

Team 1 Methodology

8,6 Technique

6

Learning

8

Standard deviation

9,5

2,0

9,0

1,6 1,2

8,5

8

8,0 6

7,5

4

0,8

Team 2

0,4 0,0

3

4

5

6

7

8

9

10

Utility

Students of Team 2

(c)

(d)

Fig. 6 Valuation of the technique and learning method of the students of course 2008–2009


2


1

Learning

0

Methodology

2

Technique

7,0

74


this is the group (T2G1) and the students (11 and 12) who performed the lowest effort during the activity. It is obvious that the extra effort that the application of the technique implies for the students and the need of team working and having a fluent communication among mates is not always willingly assumed by all the students. Besides, for some students, the assignment of very positive valuations to teachers’ activities is not quite well understood due to many and varied personal, and not academic, reasons.

5 Discussion and remarks The new teaching model introduced in European Universities since the Bologna Declaration with the aim of establishing a single European framework of high teaching, requires changes in the practical teaching of the subjects from the Computer Sciences degree. A traditional and rigid practical teaching based on performing a set of activities must not be carried out now, being those activities mainly related with programming and repeated along all the courses of the degree and performed individually by the students without a clear relationship between activities, tasks and people. Students’ development of attitudes and skills for a future personal and professional development is as, or more, important than getting a deep knowledge of a code or than performing repetitive tasks. Preparing the students for working in teams, assuming responsibilities or even leadership attitudes for problem solving is quite important, just the same as learning how to love problems making a professional use of the models and techniques of Software Engineering.

Average

8 6 4 2 0 1

3

5

7

9

11 13 15 17 19 21 23 25 27 29

1,2 1,0 0,8 0,6 0,4 0,2 0,0 Overall satisfaction

10

Standard deviation

Utility

9,4 9,2 9,0 8,8 8,6 8,4 8,2 8,0



Learning

Learning

Utility

Methodology

Methodology


Technique

Technique

Students of course 2009-2010

Knowledge

Fellowship

Teamwork

Dedication

Availability

Overall

(b) Professionalism

10 8 6 4

Commutement 80

VTR FTR

60

Documentation Depuration

40

Test 20

2 0

Communication

100 Time (hours)

Students assessment

(a)

Programming Design

0 1

3

5

7

9 11 13 15 17 19 21 23 25 27 29 Students of course 2009-2010

1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 Students of course 2009-2010

(c) Fig. 7 Valuations results from students of the course 2009–2010

(d)

Analysis Study


75

The practical teaching model described in this paper, based in the Rolling technique, allows teachers to reach those objectives, promoting the development in the students of personal and professional attitudes and skills, needed for their future personal and professional development. Valuations provided by the students, only act as a guarantor for the results obtained, which are quite higher, in its majority, to the ones obtained by the same students in other subjects of the degree where this technique is not used. The valuation results with regards to other parameters studied have had a stable behavior along the courses, which supports the analysis performed. Those valuations haven’t been impacted by the groups’ size, problem complexity or effort (hours) invested by the students in the development of the activity, as can be checked comparing the results for all the courses. Figure 7 shows the process’s valuation performed by the student of the 2009–2010 course. Due to the characteristics of the problem, a sole team was set up, made by 15 groups of two students each. The activity was carried out in three stages (plus a previous one corresponding to the development and approach of a new business idea). As can be seen in Fig. 7a and b, the 28 students that performed the final survey valuated very positively all the items related with the technique, methodology and quality or use of the teaching model. Students’ self evaluation shows a behaviour similar to the ones described previously regarding the students/groups that lead the process and acquire responsibility roles so, therefore, they are better valuated than their mates (i.e., students 6, 11, 12, 19, 20 and 27). Those students, as shown in Fig. 7d, invested more effort on the development of the activity than their mates, and/or perform the more technical and specialized tasks. This positive valuation has been also reflected in the flair had by the students on the theoretical content of the subjects. During the years the technique has been used, all the students have passed the subject, and the average mark has been between 7.5 and 8.5. Our future objective is to keep polishing the model, studying its possible application to other courses/subjects where the current high number of students enrolled, prevents its application due to the extra effort needed by the teachers and the problem when coordinating so many students. For this purpose we are carrying out studies over the variables that impact in its application. Those variables are mainly the size of the teams, the timing of the rotations, the relationships among activities and responsibilities rotations, the coordinated implementation on different subjects, etc. Acknowledgement This work was supported by the Ministry of Science and Innovation of Spain (MICINN) and FEDER (Project: TIN2009-07184). This work was awarded with the First prize in the II Call for Teaching Innovation Awards of the Social Council of the University of Cordoba.

References Alfonseca, E., Carro, R. M., Martín, E., Ortigosa, A., & Paredes, P. (2006). The impact of learning styles on student grouping for collaborative learning: a case study. User Modeling and User-Adapted Interaction, 16(3–4), 377–401.

76


Bacon, D. R. (2005). The effect of group projects on content-related learning. Journal of Management Education, 29(2), 248–267. Benarek, G., Zuser, W., & Grechenig, T. (2005). Functional group roles in software engineering teams. In Proceedings of the ACM 2005 Workshop on Human and Social Factors of Software Engineering (HSSE’05), 1–6. Casey, V., & Richardson, I. (2009). Implementation of global software development: a structured approach. Software Process Improvement and Practice, 14, 247–262. Castro-Garrido, P., Matas Miraz, G., Luque Ruiz, I., & Gómez-Nieto, M. A. (2010). Encouraging Learning and Student Motivation through NFC-based Pervasive Games. Education and Information Technologies. In revision. Coffield, F., & Edward, S. (2009). Rolling out ‘good’, ‘best’ and ‘excellent’ practice. What next? Perfect practice? Educational Research, 51(3), 371–390. Collins-Sussman, B., Fitzpatrick, B. W., & Pilato, C. M. (2004). Version Control with Subversion. Next Generation Open Source Version Control. O’Reilly Media, Inc. Council of Europe (1997). Convention on the Recognition of Qualifications Concerning Higher Education in the European Region. Lisbon. http://www.bologna-berlin2003.de/pdf/Lisbon_convention.pdf. Deibel, K. (2005). Team formation methods for increasing interaction during in-class group work. In Proceedings of the 10th annual SIGCSE conference on innovation and technology in computer science education (pp. 291–295). New York: ACM. Del Soldato, T., & Boulay, B. (1996). Implementation of motivational tactics in tutoring systems. International Journal of Artificial Intelligence in Education, 6(4), 337–378. European Commission of Education & Training (2009). European Credit Transfer and Accumulation System (ECTS). http://ec.europa.eu/education/lifelong-learning-policy/doc48_en.htm. European Network for Quality Assurance in Higher Education [ENQA] (2003). Quality procedures in European Higher Education, Helsinki: ENQA. http://www.enqa.net/texts/procedures.pdf. Goldschmid, M. L. (1971). The learning cell: an instructional innovation. Learning and Development, 2, 1–6. Goodnight, J. E., Elam, E. L. R., & Russell, D. L. (2008). The rolling cell model: An application and evaluation. Marketing Education Review, 18(3), 1–13. Hübscher-Younger, T., & Narayananb, N. H. (2003). Authority and convergence in collaborative learning. Computers & Education, 41, 313–334. Inaba, A., Supnithi, T., Ikeda, M., Mizoguchi, R., & Toyoda, J. (2000). How can we form effective collaborative learning groups? Available from http://www.ai.sanken.osaka-u.ac.jp/indexe.html. Issroff, K. (1995). Investigating computer-supported collaborative learning from an affective perspective. Unpublished Ph.D. Thesis, The Institute of Educational Technology, The Open University. Johnston, L., & Miles, L. (2004). Assessing contributions to group assignments. Assessment and Evaluation in Higher Education, 29(6), 751–768. Jones, A., & Issroff, K. (2005). Learning technologies: affective and social issues in computer-supported collaborative learning. Computers & Education, 44, 395–408. Joomla!. http://www.joomla.org/. [Last accessed: July, 2010]. Keyes, J. (2004). Software Configuration Management. Auerbach Publications. CRC Press. Luque Ruiz, I., Peña Carrilero, M. J., & Gómez-Nieto, M. A. (2008). A Learning Model in Computer Engineering Based on Collaborative Work for Enhancing of Students Abilities and Skills. Proceedings of INTED 2008 International Conference. 18–32. Matas Miraz, G., Luque Ruiz, I., & Gómez-Nieto, M. A. (2009a). Students Collaborative Work driven by Self-Students Goals. Proceedings of INTED 2009 International Conference, 3150–3159. Matas Miraz, G., Castro-Garrido, P., Luque Ruiz, I., & Gómez-Nieto, M.A. (2009b). Web-Based Management System for the Monitoring, Compliance and Evaluation of University Tutorials. Proceedings of EDULEARN2009: International Conference on Education and New Learning Technologies. 2394–2402 Matas Miraz, G., Luque Ruiz, I., & Gómez-Nieto, M. A. (2009c). University of things: applications of near field communication technology in university environments. Journal of E-Working, 3, 52–64. Matas Miraz, G., Castro-Garrido, P., Borrego-Jaraba, F., Luque Ruiz, I., & Gómez-Nieto, M. A. (2010). Ubiquitous Services for Future University. Proceedings International Association of Technology, Education and Development, INTED 2010, 5486–5495. Meng-Hsiang, H., Chen, I. Y. L., Chiu, C.-M., & Ju, T. L. (2007). Exploring the antecedents of team performance in collaborative learning of computer software. Computers & Education, 48, 700–718. Michaelsen, L. K., & Black, R. H. (1994). Building learning teams: The key to harnessing the power of small groups in higher education. In S. Kadel & J. Keehner (Eds.), Collaborative learning: A


77

sourcebook for higher education (Vol. 2, pp. 65–81). State College: National Center for Teaching, Learning and Assessment. Moodle Trust. http://moodle.org/. Accessed April, 2010. Moreno, L., Gónzalez, C., Castilla, I., Gónzalez, E., & Sigut, J. (2007). Applying a constructivist and collaborative methodological approach in engineering education. Computers & Education, 49, 891– 915. Muehlenbrock, M. (2006). Learning group formation based on learning profile and context. International Journal on e-Learning, 5(1), 19–24. NFC Forum Organization. Technical Specifications. http://www.nfc-forum.org/home. Accessed June, 2010. Oakley, B., Felder, R. M., Brent, R., & Elhajj, I. (2004). Turning student groups into effective teams. Journal of Student Centered Learning, 2(1), 9–34. Russell, D. L., & Goodnight, J. E. (2009). The rolling learning cell: a method to integrate individual assessment and team grading components in information systems curriculum team projects. Information Systems Education Journal, 7(37), 1–15. Sancho-Thomas, P., Fuentes-Fernández, R., & Fernández-Manjón, B. (2009). Learning teamwork skills in university programming courses. Computers & Education, 53, 517–531. Slavin, R. E. (1988). Cooperative learning and student achievement. Educational Leadership, 46, 31–33. Slavin, R. E. (1990). Cooperative learning: Theory, research, and practice. Englewood Cliffs: Prentice-Hall. Slavin, R. E., & Karweit, N. L. (1985). Effects of whole class, ability grouped, and individualized instruction on mathematics achievement. American Educational Research Journal, 22(3), 351–367. Smith, K. A. (1995). Cooperative learning: Effective teamwork for engineering classrooms. In Proceedings of Frontiers in Education Conference (FIE 95), 1, 13–18. Wang, Q. (2009). Design and evaluation of a collaborative learning environment. Computers & Education, 53, 1138–1146.

Rolling: A new technique for the practical teaching in computer ...

Rolling: A new technique for the practical teaching in computer ...

Suggest Documents

Challenging the Norm in the Teaching of Practical Computer Science

Challenging the Norm in the Teaching of Practical Computer Science

A TECHNIQUE FOR ACCELERATING THE ... - Computer Science

Retrospective Pretest: A Practical Technique for Professional ...

A Practical Technique for Process Abstraction - CiteSeerX

A NEW STABILIZING TECHNIQUE FOR

Computer Surgery 3D Simulations for a New Teaching ... - Unileon

Computer animation - a new method for teaching, communication and

PACKET tracing: a new paradigm for teaching computer network ...

A new experimental technique for determining the

A New Method of Teaching Skiing - Alexander Technique

a new technique for hydropower enhancement in new ...

TEACHING NOVICES THE HANDSTAND: A PRACTICAL APPROACH ...

the effectiveness of make a match technique for teaching writing ...

Computer-Assisted Joint Space Area Measurement: A New Technique

Selecting a Processor for Teaching Computer Architecture

A Technique for Detecting Plagiarism in Computer ... - Semantic Scholar

Chung's swing technique: a new technique for ... - Semantic Scholar

Rolling out Agile in a Large Enterprise - IEEE Computer Society

A Mathematical Technique for Analyzing Folds With the Computer

Practical Techniques for Teaching Culture in the EFL Classroom

A Computer Technique for the Solution of Laue Back Reflection ...

Practical Techniques for Teaching Culture in the EFL Classroom

Teaching Software Engineering in a Computer