The Practice Training in the Software Engineering Education

Ping Huang, Mingrui Chen, Shaofan Chen College of Information Science & Technology

Hainan University PO Box570228, Hainan, China

pinghain@gmail.com, mrchen@hainu.edu.cn, shaofanchen@yahoo.com.cn

Abstract

Software engineering, like the other engineering

disciplines, faces increasing pressure to provide students with those skills required both to succeed in their first professional job and to engage in lifelong learning. This is a curriculum design challenge that requires considerable deliberation. As a reflection of the movement in higher education from teacher-centered to student-centered learning, many methods, such as the application of situated cognition theory, were adopted in our course of software engineering. The practice training was proposed in the semester-long software engineering course to meet the goals that help students to understand further about the software engineering theory and put it into use with personal meaning. The process of the practice training was elaborated in the paper. A bulletin board was built for resource sharing on a local server. All the students enrolled in the course were divided into several teams for project cooperation. After the training an interview study of students was conducted for ascertaining how they felt the process changed the way they learned and the issues they encountered in working. Three issues were concluded according to the products the students performed in the practice training. The recommendations about how to improve the process were also provided in this paper. Keywords: Software engineering, teaching model, student-centered learning, situated cognition theory, practice training. 1. Introduction

Software engineering, like the other engineering disciplines, faces increasing pressure to provide students with those skills required both to succeed in their first professional job and to engage in lifelong

learning. This is a curriculum design challenge that requires considerable deliberation.

ABET, in Engineering Criteria 2000 [1], requires that all engineering programs demonstrate their effectiveness by assessing eleven student learning outcomes. These outcomes include the expected engineering related goals such as “an ability to design a system, component, or process to meet desired needs” and more ambitious goals such as “recognition of the need for and an ability to engage in lifelong learning”. This transition to accreditation based on how well students can demonstrate both knowledge and skills is a reflection of the movement in higher education from teacher-centered to student-centered learning.

With this is mind we seek a strategy to expose students' mental activity and processes required in their learning. To do so the practice training was proposed in our semester-long software engineering course.

In section two the differences between the two models (teacher-centered learning and student-centered learning) were described in detail.

In section three we analyzed the character of the software engineering course and introduced some alterations we adopted in education model, such as the application of situated cognition theory. For improving the learning ability of students, we adopted practice training in this semester.

The process of the practice training was elaborated in section four. And continued, We conducted an interview study of students after they finished the training to ascertain how they felt the process changed the way they learned and the issues they encountered in working.

Some issues and problems were put forward so that we could improve the process later on.

It showed that the practice training was valuable to facilitate students’ understanding of knowledge. We also provided some recommendations about how to improve the process in our course.

The 9th International Conference for Young Computer Scientists

978-0-7695-3398-8/08 $25.00 © 2008 IEEE

DOI 10.1109/ICYCS.2008.443

2636

2. The innovation of teaching model

The teacher-centered tradition has been the cornerstone of higher education, with engineering education merely adhering to the dominant doctrine, for what seems an eternity. Bowers and Flinders [2] describe a variation of the teacher-centered model, teacher as "classroom manager", in which the learning process is likened to industrial production, within which students become "products", behaviors are expressions of "exit skills", "competencies" and "outcomes".

In this model, the student simply rides the assembly line of learning, quietly and dutifully accepting all inputs as does a skeletal frame on an automobile manufacturing plant's assembly line[3].

According to cognitive psychologists and educators, instruction is most effective when students are encouraged and even expected to become actively involved in their own learning, thereby shifting the focus from what the teacher does to what the students do. The shift to a student-centered approach is fueled by a number of instructional research projects [4][5][6]. Constructivism is the theory of learning that informed these studies. In constructivism, the learning process is conceived as an activity in which new information is linked to prior knowledge. Thus, the things we “know” are tentative, and are refined and changed through assimilating or constructing knowledge through activities such as self-explaining, writing, interacting with others and with other ideas. In addition, knowledge is more than the contents of a vessel; it includes declarative knowledge, interrelated structure of constructs and how-to skill. The implications for teaching practices are enormous. Students connect what they are learning to their own experiences and current knowledge, thus making their learning conceptually coherent and personally meaningful. The key teaching practices include opportunities to reformulate and articulate newly found meanings. This activity is critical to successful learning.

3. The alterations we adopted in software engineering course

The software engineering course is a required course in the Computer and Information Science Department. The course is part of the requirements for both computer science and computer engineering majors, and is taken during their senior year. The content of the course is typical of such courses in the range of topics. The intent is to cover the software development lifecycle including those practices

associated with large-scale development, e.g., configuration management and software quality assurance. The course has both a lecture and laboratory component [7][8].

As a reflection of the movement in higher education from teacher-centered to student-centered learning, many methods were adopted in our course of software engineering. Such as the application of situated cognition theory [9], which argue that knowledge is situated, being part of a product of the activity, context, and culture in which it is developed and used [10][11].

We designed several models of the situated cognition teaching in the software engineering course. For example, we adopted the method of anchored instruction. Differing from the traditional teaching model, anchored instruction focus on the use of the knowledge. In this model, learning and teaching activities should be designed around an "anchor" which is based on a contextualized case study or problem situation.

For example, when the software development process models being described, a problem with special context was provided: “Provided that you are a project manager of a software company, now a client requests you to develop an application system for urgent use, the client has prescribed the function requirements of the system and the time for delivering. The trouble is the programmers cannot develop the system with so many functions in the stated time. So, what will you do? Accept the request or reject it? If you accept, how will you solve the problems? ” Anchored instruction requires putting the students in the context of a problem-based story. The students “play” an authentic role while investigating the problem, identifying gaps to their knowledge, researching the information needed to solve the problem, and developing the solutions. To solve the above problem, students brought forward many kinds of solutions: “we can complete the project in advance relying on the overtime of the employees”; “ the application system can be carried out by making the most use of the existed components to shorten the finish time”, etc. We got passionate responses in the course. As a result, the students increased their capability for knowledge and could solve the realistic problems independently.

For improving the learning ability of students, we adopted practice training in this semester. In this training each student was required to complete a semester-long team project. Teams of 4-6 students worked together to specify and build a product during the semester. The object of the practice training is: to understand and handle with the knowledge; attach students to the software development process; improve team process.

2637

4. The process of the practice training

As is normal in software project development, there were considerable variations in the skills and abilities of the students involved. The students had a broad range of backgrounds: a few of the students had significant industry experience, while others had more conventional academic backgrounds and had limited experience. So, in the practice training, we, as the instructors, chose project leaders who met with us to receive a draft problem statement. The leaders reviewed the resumes of those enrolled in the course and chose individuals they wished to have on their team. They were asked to defend their choices based on project criteria and the contents of the resume.

A bulletin board was set up for the sharing of resources on the local server. Students had Web access to this bulletin board. All the sources and documentations the development process need were available through this Web interface, such as, the purpose and requirement for the curriculum design, executive steps, document template, design criterion and detailed paradigm. In addition, with restricted permission students could access some whole real cases of a certain computer company in Haikou and the utilities would be needed for modeling. However, it was a pity that the bulletin board did not provide functions for collaboration. The communication between instructors with students or among students themselves mainly depended on emails.

Each project had a real customer with whom the teams met to determine the requirements. Each person on the team was assigned a process role, (quality assurance, configuration management, project planning, project tracking) for the duration of the project. The process roles were distributed among team members through negotiations among team members and the project leaders as were the development activities, e.g., design and coding.

A competition was held for each team to set out their production at the ending of this semester with some prizes provided. In the stated time, every team gave a presentation in the turn of sortilege. Every team introduced the members with process roles, explained the models they set up in the stage of analysis and design. The teams were also required to perform their products after their presentation. To ensure the justice, every team recommended a representation to judge the productions. The instructor also joined in the jury. The graded criterion was set up beforehand which included the appearance and manner, the collaboration within the team, the rationality and regularization of the built models and the effect of the software production, etc.

The jury marked the productions according to the criterion and the competition result was determined with the sum accounted by all the marks. An awarding ceremony was carried on after the competition and as a souvenir all the students took a photo with the instructor. The students appeared high enthusiasm throughout the process. 5. Interview study

We were interested in whether students had seen a value in the practice training, particularly in its support of learning, so an interview study carried on after the competition.

The software engineering course enrolled 68 students during this semester. All of the students were computer science majors. We selected 12 students at random from each group to participate in the interview. A research assistant conducted the interviews and recorded the responses.

Four benefits were mentioned by at least 6 students. First, they appreciated the student-centered model such as the practice training, which is helpful for them to connect what they are learning to their own experiences and current knowledge (mentioned by 10 of the 12 students). Second, they found this practice facilitated their team skill that is important in cooperation project (8 students). Third, they liked being able to attain the integrated experience of software development (10 students). Fourth, they liked being able to access so much useful material from the bulletin board on the web (6 students).

The students' biggest frustrations all related to the communication during the team cooperation. 6. The issues and problems observed about project development

Observing on the productions performed by the teams, we found out some problems emerged in this practice training. 6.1. Irrationality in dividing the work

The development activities were distributed among team members through negotiations among team members and the project leaders.

Most of the teams divided their work in this mode: first, one or two members met to the customer for requirements and after which affirmed by the both sides the requirements document was composed. Then, the team discussed about the module partition of the software system and each member took responsibility for the analysis and design of one or two modules.

2638

Thus, the final design of each module is always irrespective to others and the whole software architecture is lack of holistic consideration, that is, the final design of classes in the software is lack of conformity and optimization. So, it is certainly poor in solidity and extensibility of the software architecture.

Of course, there were a few teams did well in the integrality of their products. We found in those teams there were always one or two team members with practice experiences leading all the work during the development process.

6.2. Inadequate in communication

Another problem exposed in this training is about communication. Keeping well communication is one of the sticking points for success team process. In this practice training, email and interview discussion were used as the main communication mechanisms. But, the team had limited time for interview because of the heavy study work in this semester and many troubles could not be best solved just throughout emails. Especially, at the end of the design stage of the project, the module design should be integrated into a whole system and that would need team members to discuss frequently. Observing on the productions, we found most of the teams made deficient design in the system integration.

Obviously, how to provide efficient and handy communication is a problem desirable to solve in the next step. 6.3. Misunderstanding in conception

The rationality and standardization of the model is one of the graded criterions in this practice training. All the teams did well in the aspect of standardization and their models built were aesthetic and accorded with standard. However, in the other aspect of rationality, many mistakes exposed. It showed the insufficient understanding for knowledge the students learned in the lecture component.

For example, some teams set up state diagrams for all the classes within the system, including some simple or unimportant classes. As we know, a state diagram shows the possible states an object can take, the events that trigger the transition from one state to the next, and the actions that result from each state change. Usually, an object state is related to a set of attribute values, and events occur when messages are sent or received. Thus, a state diagram is needed only for classes where the objects exhibit dynamic behavior, with many attribute values and messages.

Some teams set up activity diagrams after they had designed the classes and their associations. It showed obviously the students had misunderstood the functions of activity diagram. We usually use activity diagrams to display all the activities that can occur in system and though analyzing those activities we can find out the objects which responsible for those actions. Of course, the system activity diagrams should be built before the class diagrams.

There are also many other problems have occurred and different problems appeared in the different teams. It indicated some methods should be used to assess the knowledge the students learned from the course so that we can correct those misunderstandings in time. 7. Conclusion and future work

Practice training provided the opportunity for students to join in an actual team project as a method in the shifting process from teacher-centered model to student-centered model which help students to understand further about the software engineering theory and put it into use with personally meaningful. Our interview indicated that majority of students appreciated the practice model through which the students may have actually improved in reflective practice.

The interviews and our analysis of the student’s outcomes during the teaching of this course indicate a number of areas requiring increased attention. First, the functionality of the bulletin board to support team projects was woefully inadequate. The board provided all kinds of resources for student to access except for thinking of interaction. All the discussions could only be done with limited communication manners such as email. The functions of on-web discussion and resource uploading should be added into the bulletin board for reinforcing the share of resources and source codes.

The second, more actual project material should be provided in the lecture course, for most of the students being lack of team skill. This material would cover the basics of teaming--team roles, effective meetings, communication styles, and conflict resolution. And after the students’ reading, a test about team knowledge could be designed to test their understanding of how effectively teams function.

The last, it should be valuated that how the students identified the knowledge learned from the software engineering course. Much research conceived concept maps to be indicative of cognitive status [12][13]. Concept maps are network diagrams in which concepts (nouns) are nodes and the relationships between concepts (verbs) are links. They are directed, acyclic

2639

graphs consisting of a set of concepts and a non-empty set of relationships (associations between concepts). Researchers in this area [14][15][16] have made a case that concept maps provide a measure of structural knowledge, that is, that there may be a relationship between what is actually known by the learner and the external representation of this knowledge as a concept map. They have been successfully used as pedagogical tools and as assessment devices. Further research indicates teachers are able to use student created concept maps to identify those specific areas within the curriculum that should be modified in order to promote a greater understanding of the subject matter.

In conclusion, this paper showed that the practice training was valuable to facilitate students’ understanding of knowledge in ways that can provide interactive model for course and curricular improvement. Acknowledgment

This work was done under the auspices of grant No.hdjy0817 from the Education and Teaching Foundation Assessment of Hainan University. References [1] Accreditation Board for Engineering and Technology, Inc. “Engineering Criteria 2000: Criteria for Accrediting Engineering Programs”, 1999. http://www.ele.uri.edu/faculty/daly/criteria.2000.html [2] C.A. Bowers, and D.J. Flinders, Responsive Teaching, teachers College Press, New York, 1990. [3] G.D. Catalano, and K. Catalano, “Transformation: From Teacher-Centered to Student-Centered Engineering Education”, 1997 Frontiers in Education Conference, IEEE Computer Society, Pittsburgh, PA, USA, 5-8 Nov 1997, pp. 95-100. [4] R. Creese, “A Project Centered Engineering Program”, Journal of Engineering Education, ASEE, Washington DC, Vol. 78, No. 2, 1987, pp. 100-104. [5] P.C. Knox, D.A. Sabatini, RL. Sachs, P.D. Haskens, L.W. Roach, and S.W. Fairbarn, “A Practitioner-Educator Partnership for Teaching Engineering Design”, Journal of Engineering Education, ASEE, Washington DC, Vol. 84, No. 1, 1995, pp.5-12. [6] J. Carroll, R. Fearn, and R. Rivers, “Flight Test Engineering - An Integrated Design/Laboratory Course”, Journal of Engineering Education, ASEE, Washington DC, Vol. 85, No. 1, 1996, pp. 73-76.

[7] R.L. Upchurch, and J.E Sims-Knight, “Portfolio use in software engineering education: an experience report”, IEEE Frontiers in Education Conference 2002, IEEE Computer Society, Boston, MA, USA, Vol. 3, 2002, pp. S2G-1- S2G-6. [8] S.L. Pfleeger, Software Engineering-Theory and Practice, Higher Education Press, BeiJing, 2001. [9] P. Huang, “The Application of Situated Cognition Theory in the Course of Software Engineering”, modern computer, ZhongShan university, Guangzhou, Vol. 261, No. 6, 2007, pp. 52-53. [10] J.S. Brown, A. Collins, and P. Duguid, “Situated Cognition and the Culture of Learning”, Educational Researcher, American Educational Research Association, Washington DC, Vol. 18, No. 1, 1989, pp. 32-42. [11] Z.X. Zhang, and Q.L. Wu, “A Review of Researches on Situational Learning Theory”, psychological Science, psychological institute of china, ShangHai, Vol. 28, No. 1, 2005, pp. 125-127. [12] M.A. Ruiz- Primo, and R.J. Shavelson, “Problems and issues in the use of concept maps in science assessment”, Journal of Research in Science Teaching, NARST, Reston, VA, USA, Vol. 33, No. 6, 1996, pp. 569- 600. [13] I.M. Kinchin, D.B. Hay, and A. Adams, “How a qualitative approach to concept map analysis can be used to aid learning by illustrating patterns of conceptual development”, Educational Researcher, American Educational Research Association, Washington DC, Vol. 42, 2000, pp. 43-57. [14] D.H Jonassen, T. Reeves, and N. Hong, “Concept mapping as cognitive learning and assessment tools”, Journal of Interactive Learning Research, AACE, Chesapeake, Vol. 8, 1998, pp. 289–308. [15] K. Markham, J. Mintzes, and G. Jones, “The concept map as a research and evaluation tool: Further evidence of validity”, Journal of Research in Science Teaching, NARST, Reston, VA, USA, Vol. 31, No. 1, 1994, pp. 91-101. [16] J.E. Sims-Knight, R.L. Upcherch, N. Pendergrass, T. Meressi, P. Fortier, P. Tchimev, R. VonerHeide, and M. Page, “Using Concept Maps To Assess Design Process Knowledge”, 2004 Frontier in Education Conference, IEEE Computer Society, Savannah, GA, USA, Vol. 2, 2004, pp. F1G- 6-F1G-10.

2640