SOME IMPORTANT FACTORS IN TEACHING SOFTWARE ENGINEERING COURSES Haibin Zhu, Senior Member, IEEE Dept. of Computer Science, Nipissing University, 100 College Drive North Bay, ON P1B 8L7
[email protected] ABSTRACT Traditional ways to educate software developers have not produced the supply and quality of developers needed to satisfy the growing demand. We need to retrospect what we have done in the traditional ways and improve our software engineering education. This paper discusses important factors in teaching software engineering courses, i.e., paying more attention to the abstraction ability of students, introducing real large practical project in the courses, organizing courses in a series way and others. Keywords: Factors; Teaching; Software Engineering.
1. INTRODUCTION Software engineering (SWE) is a complex and challenging undertaking. Teaching undergraduate students SWE is even more complex and challenging [15]. Teaching first year undergraduate students SWE ideas is much more complex and challenging. When I was participating in OOPSLA’03 (2003 International Conference on Object-Oriented Programming Systems, Languages and Applications) conference, some professors stated that the common difficulties are teaching abstraction which is a fundamental concept and methodology in SWE. Actually, abstraction ability is the most important learning ability for a person. However, obtaining the learning ability is a life-long activity for a person. The greatest Chinese educator Confucius stated 2000 years ago: “吾十有五而志于学, 三十而立, 四十而不惑, 五 十而知天命, 六十而耳顺, 七十而从心所欲, 不逾矩”, i.e., “At fifteen my heart was set on learning; at thirty I stood firm; at forty I had no more doubts; at fifty I knew the mandate of heaven; at sixty my ear was
obedient; at seventy I could follow my heart's desire without transgressing the norm.” This statement tells us that a person’s abstraction or learning ability improves as the age grows. Therefore, we need to pay more attention to the abstraction ability level or the mental age of students in teaching. The evaluations of my courses in Nipissing University and NJIT (New Jersey Institute of Technology) also demonstrate this situation. SWE professors must have the additional ability to convey their knowledge to students correctly and reliably, to teach required skills, to provide perspectives, and to infuse the students with interests, curiosity and enthusiasm [7]. When I was learning a SWE course in the 1980s, the course only offered the fundamental concepts, terminologies, principles and methodologies. I was not involved in any real project at that course. All the SWE knowledge I obtained in my master’ s study was from a graduate project of one and half years. Nowadays, no one is considered as successful if he or she did not offer a large project that requires team work in a S W E course. This shows us the new development and requirement for SWE education. Just as stated by Mary Shaw, a professor from Carnegie Mellon University [13]: “The educational community itself is increasingly from lecture-format courses to team projects, problem solving, direct involvement with actual development, and other formats that require students to exercise the ideas they are learning”. Liu et. al. [ 10] also suggested in teaching S W E some important aspects of software development in real world includes team-based development, problem definition from real-world, managed development process, reflecting an iterative software development approach, etc. ACM/IEEE Computing Curricula 2001 (CC-2001) [1] recommended arrange knowledge units into groups. It could provide the properties of systematic, advancing gradually, decreasing of repetitions and time-saving.
These properties are believed important in education. At Nipissing University, we not only require but also have to arrange the courses into groups because our faculty number is small. I have offered even courses relevant to programming and software engineering. It gives me the opportunity to arrange the courses in a series style. From our practice, we believe it a successful and efficient way to teach SWE courses. This paper is arranged as follows. Section 2 discusses the lessons learned from the evaluations of my courses taught in the past years , i.e., we should pay more attention to the levels of students’abstraction abilities in teaching. Section 3 presents a practice to introduce large project into the course of software engineering; Section 4 demonstrates why and how to offer a computer science program by arranging course series. Section 5 discusses many common factors that are very important in teaching SWE courses. At last in section 6, we conclude that SWE education requires not only high-quality lectures, but also advanced education and teaching methodologies and tools, systematical knowledge organization and deep involvement of practices.
2. PAYING ATTENTION TO THE STUDETNS’LEARNING ABILITIES In China, as an education tradition, an instructor is required to have a barrel of “water” if he or she wants to give the students a cup of “water”. This states that if a professor wants to be successful in offering a class, he or she should at first master the course materials thoroughly. That is why a PhD degree is required for a person to be qualified as a professor for most universities, because a PhD degree holder is assumed to have mastered the fundamental knowledge in the curriculum from which he or she obtained the degree. However, I hope to emphasize in this section that only enough knowledge in the relevant discipline is not enough to be a good professor. I have participated in many large real software engineering projects as a programmer, a designer, and a manager and taught courses in computer science and software engineering for ten years. The eighteen different courses I taught at different levels as follows are all among the computer science and SWE curricula . 1. The current courses in Nipissing University: [1] Introduction to Computing [2] C++ Programming [3] Object-Oriented Programming
[4] Programming Paradigms [5] Distributed Systems [6] Software Engineering [7] Computer Security 2. The courses taught in New Jersey Institute of Technology (NJIT), USA [1] Operating System Designs that is a graduate course [2] Introduction to UNIX Operating System that is third year c ourse [3] Introduction to Computer Science II that is a first year course [4] Object-Oriented Programming with C++ that is a graduate c ourse [5] Principles of Operating Systems that is a third year course [6] Machine and Assembly Language that is a second year course [7] Advanced Programming Environment & Tools that is a distance learning course for graduate students 3. The courses taught in China [1] Object-Oriented Principles and Applications that is a course for graduate students [2] Distributed Systems that is a course for graduate students [3] Advanced Computer Architecture that is a core course for graduate students [4] Computer System Performance Evaluation that is a course for fourth year students From my teaching experiences and engineering background shown as above, there should be no any barrier for me to master all the course materials. I am confident that I have enough “water” to give the students , especially for the first year undergraduate students . In Nipissing University, I put almost similar efforts to teach every course: • using similar teaching tools such as power point slides, programming environment to demonstrate real programs instantly in the class; • preparing several hours for each two or three hour lecture; • trying to use examples or metaphors in our normal lives to explain the principles and concepts in programming and software design; and
•
applying the teaching methodology of “methodology first and language second”[17] In introducing fundamental concepts . However, surprisingly to me, I obtained different comments and evaluations from my students to my teaching. Some comments obtained from the first year students are totally different from those from the senior students. The senior students have given me more complimentary comments than critical comments but first year students were more critical than complimentary in their comments . The following comments are some typical examples from the students’evaluation comments. The fourth year students in the course of Software Engineering: • “The course was presented in a clear and structured form. We had a lab component which followed the lecture seamlessly. Dr. Zhu is a great professor. He always gives us great examples while he presents. His lectures are very interesting and you can see that he enjoys the materials that he teaches.” • “The course was well presented and useful for future career plans. He is very knowledgeable and provides all necessary help.” The third year students in the course of Object-Oriented Programming: • The course is “great”; “useful stuffs are nicely presented”; and he is “always prepared”. • “Very effective in teaching the concepts”. • “He knows the subject matter very well and does a good job explaining difficult concepts.” • “Although there are occasional language barriers, I think for the most part we understand each other.” The third year students in the course of Programming Paradigms: • “It is a good course organization”. • “He has good subject knowledge. His talks used powerful metaphors.” • “Whatever you are paying him, it is not enough.” • “The course is overall very good”and “He is great.” However, I got the following comments from a first year (2nd semester) student in the course of C++ Programming: • “The instructor presented all the required criteria, however, he did not make it very interesting and it was difficult to follow his lecture at times”.
Some first year students in the course of Introduction to Computing gave comments as follows: • “He tries to explain questions with metaphors which only confuse us more” and “I know he tries really hard but I have hard time learning from him. He doesn’t understand that programming doesn’t come easy to every one.” • “C++ should not be a mandatory course for math majors because though some of the information applies to other courses, it is unnecessary for people who do not want to pursue a career or education in computer programming! He is a very intelligent and nice instructor. However, he is very hard to understand.” Note that we use C++ in this course as a language to introduce programming concepts. Table 1 gives the evaluations from the students in Nipissing University. I offered all the courses at the first time with new books, new syllabi and new schedules. Some hints in the tables mention that I had offered some similar courses before I went to Nipissing University. These experiences might affect the evaluations a little bit. From the evaluation tables, we could extract the fact that my courses are more welcome by senior students than by first year students. I can also infer that I have not transferred my knowledge to the first year students as what I expected. Table 1 The eva luations in Nipissing University (From Fall 2002-Winter 2003) Course Level Fourth Year
Course Name Software
Evaluation Grade
Comments
4.22/5.0
Average of the 1st time and the 2nd time to teach 1st time to offer similar to a course in NJIT 1st time to teach 1st time to teach 1st time to teach
Engineering
Third year (3rd course)
Objectoriented
4.36/5.0
Programming
Third Year (2nd course) Third Year (1st course) First Year (2nd computer science course) First Year (1st computer science course)
Program Paradigm Distributed Systems C++
4.28/5.0 4.18/5.0 3.81/5.0
Programming
Introduction
to Computing
3.90/5.0
1st time to teach
Fig. 1 and Fig. 2 describe the evaluation differences among different level students with more understandable graphs. Evaluation 4.4 4.3 4.2 4.1 4 3.9 3.8 3.7 3.6 3.5 1st 1st 3rd 3rd 3rd 4th year- year- year- year- year - year 1st 2nd 1st 2nd 3rd
Fig. 1. The column graph for the evaluations of my courses in Nipissing University
Table 2 lists the evaluations from the students of New Jersey Institute of Technology (NJIT), USA. This table shows the same situation as that shown in Table 1. Fig. 3 and Fig. 4 use different kinds of graphs to show the same results as shown in Table 2. The first year students’evaluation also showed that my teaching is not as successful as my teaching other courses to senior students . By comparing the lines for the first year students’ evaluation in table 1 with those in table 2, we can find some improvements I made to improve my teaching first year courses, even though there might be much differences between different universities. Another factor affecting the evaluations might be that more mature students registered in the first year courses of Nipissing University.
Evaluation 3.5 3 2.5 2 1.5 1 0.5 0
Evaluation 4.5 4.4 4.3 4.2 4.1 4 3.9 3.8 3.7 3.6 3.5
1st year
Third year course Second Year course First Year course
3.35/4.0
1st time to offer
Advanced Operating System Operating System principles Assembly language
3.10/4.0
2.86/4.0
Some graduate students register this course 1st time to offer
2.45/4.0
1st time to offer
Introduction to Computer Science II
2.1/4.0
1st time to offer
2n d
OOP with C++
-1s t
1st time to offer
Operating System Design
Comments
gra du ate
Evaluation Grade 3.41/4.0
gra du ate
Course Name
Evaluation
4th ye ar
Course Level Graduate second course Graduate first course Senior Course
graduate -1st
4 3.5 3 2.5 2 1.5 1 0.5 0 3rd ye ar
Fig. 2. The line graph for the evaluations of my courses in Nipissing University Table 2 The evaluations in NJIT (From Fall 1999 -Spring 2002)
3rd year
Fig. 3. The column graph for the evaluations of my courses in New Jersey Institute of Technology
2n dy ea r
1st 3rd 3rd 3rd year 4th year year- year-1st year-3rd 2nd 2nd
1s t ye ar
1st year-1st
Fig. 4. The line graph for the evaluations of my courses in New Jersey Institute of Technology From the evaluations, we could find an interesting fact, that is, the senior students give me higher grades than the students at the lower levels. From the comments, we found that senior students evaluated courses mainly based on the expertise of the instructors but the first year students evaluated courses mainly based on the knowledge they obtained. The instructors could not get a good evaluation even the students admit that the instructor knows everything of the course. Based on
what efforts I have paid to the courses, I can only infer that the abstraction and learning abilities of first year students are not as good as that of senior students. The differences make my teaching achievements very different. Therefore, we should pay more attention to the students’ abstraction and learning abilities to understand the instructors. The cartoon used by Craig [4] as shown in Fig. 5 is very interesting. It shows the difficulty of education. If a professor and the students have ht e same mental model in a course, it is easy to convey the knowledge of the professor to the students. But if it is not the case, the professor should at first to help students build the same mental model and then transfer the knowledge. Without a common or compatible mental model between the professors and the students, the teaching would be a failure. That is why sometimes a good researcher is not definitely a good educator. This situation also demonstrates that definite prerequisites are required for most courses.
Fig. 5. T he different mental models between two persons [4] Many professors emphasize that the fundamental concepts of object-oriented programming should be taught in early years [ 3]. However, from my experience, this is not totally true, because the students have not built a common mental model as required to accept the knowledge of object-oriented programming. We still need to help our students to collect enough prerequisites for object-oriented programming before teaching them the whole bunch of knowledge of objectorientation. As a summary, we should use different methodologies to teach courses for students at different levels. W e must pay more attention to the learning abilities of first year students. We must remember that some first year students do not grow up enough to obtain knowledge in the same ability level as mature students, because they have different mental models for learning.
3. TEACHING SWE COURSES WITH REAL PROJECTS According to ACM/IEEE CC2001 [1], “Software engineering is the discip line concerned with the applications of theory, knowledge, and practice for effectively and efficiently building software systems that satisfy the requirements of users and customers. Software engineering is applicable to small, medium, and large-scale systems. It encompasses all phases of the life cycle of a software system. The life cycle includes requirement analysis and specification, design, construction, testing, and operation and maintenance.” A software engineering course should employ engineering methods, processes, techniques, and measurement. Software development involves an individual developer or a team of developers, and requires management skills, analytical skills and the choosing the personnel, the equipment, the tools, the methods, and approaches that are most applicable for a given development environment. To meet the above requirements , we must introduce large real projects to let the students to acquire such kind of knowledge. Stiller proposed six steps for effective software engineering pedagogy [15]: • Make SWE real; • Make SWE fun; • Make SWE critical; • Make SWE accessible; • Make SWE successful; and • Speak with uniform, consistent voice. The above suggestions are the same as what we would like to emphasize. Introducing real projects into a SWE course is actually relevant to the first five steps as listed above. A real large project will make a SWE course • Real: the project is a real project. • Fun: doing what students like to do is fun. • Critical: a real project will make the students do as the SDLC (Software Development Life Cycle) requires. • Accessible: the project requires the students to use tools such as project managers, diagramming such as UML notation modeling and standard documentation such as IEEE and ISO 9000. • Successful: with the project, the students would like to continue their work in the SWE course and to expand it into a research project that will let them to see their real successfulness in a real SWE project.
In my teaching software engineering in Nipissing University, I first handed out a guideline for the projects in this course including suggested project lists, schedules, document guidelines and requirements, meeting skills and role distributions. I requested the students to form a three to five student group in the first week and asked them to meet at least one time a week. With the progressing of the course, I asked them to hand in documents for different steps of the SDLC such as a project plan, a analysis report, a design report, an implementation plan, a maintenance plan, and source codes. Fischer et. a l. [6] point that coding and testing are mostly trouble-free in software engineering courses. They even suggest a large project that involves nine students. As for the projects of the course, I emphasized more on designs than on coding and testing. My major idea is that the larger the project, the more relevant to real software engineering. Therefore, I let the students choose projects relatively large and impossible for them to complete in a semester when the course is done. The students paid more on project plans, designs and documents. This trained them on a higher level than just a programmer. Two project examples as follows demonstrate that the real projects help the students practice all the steps in software engineering except coding and maintenance. Example 1 is a project called Visual Academic Planner. The team includes four students who took the roles of the planning manager, development manager, quality manager and the team leader. They met every week with notes as shown in Fig. 6.
Fig. 6. A meeting note for the team
They completed the requirement document, the analysis document, the design document, and the final document which reflect their real understanding about software engineering. Example 2 is a project called 3D Visual Model. The team is composed of five students. They took the roles of project leader, development manager, planning, manager, quality manager and support manager respectively. Fig. 7 shows their economic assessment for their project. It s analysis is almost an actual project economical assessment. This course project was finally developed to a research project for the students relevant.
Fig. 7. An economic assessment in a project In the team projects, the students are trained with many skills required as software engineers, such as analytical, managerial, communicational, and cooperative skills. They are required to distribute their assignments evenly and clearly. They are also required to abide by the team rules and schedules to coopera te with each other. They must respect each other to keep a comfortable atmosphere of the team. To evaluate the team projects, I gave the students a whole evaluation to the documents they completed. As for each student’s performance, I asked them to evaluate their peers with the criteria as follows: • Participation: 10% • New idea: 25% • Comment: 20% • Cooperative work: 20% • Concrete work: 25% Normally, they could evaluate their peers in fair ways. These evaluations provided me good references to give a grade for each student involved in the project.
From the comments and evaluations of the students , I believe this course successful (See the comments in section 2 for the details of comments and evaluations).
4. ARRANGING COURSES IN SERIES In China, we emphasized that the all the courses of a program should be grouped into several related course series. It is also the similar ideas to arranging knowledge bodies systematically in the ACM/IEEE Curriculum 01 (early version as curriculum 91). The benefits to arrange classes in series are as follows: • Systematic: it is easy to arrange knowledge units across all the courses in the series. • Easy to manage: it is easy to let the professors and students understand the prerequisites of a course. • Saving resources: it is easy to check the duplicate knowledge units across the courses in the series. The professors do not to teach the knowledge units that have been covered by other course. The instructors can save time to teach more contents; • Help ing the students learn knowledge gradually; and • Concentrating specific contents in relevant courses. That is also why most training schools that cannot offer a whole program like to offer course series. In this way, they can attract more students and obtain the better benefits with pursuing higher ratios between performance and cost in their teaching. In Nipissing University, we have to arrange the courses into groups because our faculty number is small. In our Computer Science Program we organize three course series: Hardware/Operating Systems, Programming/Software Engineering, and Computer Foundation/Application. • The Hardware/Operating System series includes Digital Systems, Machine Structures, Operating Systems, Digital Computation, Robotics and Artificial Intelligence, Artificial Neural Netwo rks, and Real-time Systems. • The Programming/Software Engineering series includes Introduction to Computing, C++ programming, Object-Oriented Programming, Programming Paradigms, Distributed Systems, Software Engineering; Human Computer Interaction; Project Management and Computer Profession.
•
The Computing Foundation/Application series includes Mathematical Computation, Theory of Computing, Database Management and Database Administration, Computer Graphics, and 3D Graphics. With three full time professors, we offered almost all the courses that are required for the four year honors degree of computer science. Because I teach almost all the courses for the Programming/Software engineering series, I have the opportunity to arrange the course contents in an optimal way. For example, originally, I had one three hour lecture for security of distributed systems in the course of Distributed Systems, the students felt frustrated because the schedule was too tight and they had a hard time to follow up all the contents offered. When I prepare d to teach the course of Computer Security, I found that there would be a special unit about security of distributed systems in the course of Computer Security. Therefore, I rearranged another three hour lecture to offer a lab on NFS (Network File Systems for UNIX). This lab helped students practice the knowledge they just learned from the former lectures and understood more about the fundamental concepts and principles in the lectures. Another example is that when I found that there would a course of Project Management for the fourth year students, I rearranged a two hour lecture that mainly discussed project management into a new schedule so that I had more time to teach the applications of DFD (Data Flow Diagrams) and UML (Unifie d Modeling Languages ). The third example is about the contents taught in programming courses. When I first t aught the course of Object-Oriented Programming in 2002, I need ed to teach many mechanisms in C++ because they did not learned in the courses of Introduction to Computing C++ Programming. When I taught both the courses, I covered almost all the contents relevant to C++ programming. By this rearrangement, I saved one third time of the course of Object-Oriented Programming this year (2004) to offer Java programming. In fact, the students obtained more skills than before with the same tuition. Fischer et. al. [6] mentions the teaching of OOA (Object-Oriented Analysis) and OOD (Object-Oriented Design) in their teaching software engineering: • OOA is hard wo rk! • Architectures and OOD need much experience. In my experience of teaching software engineering, I did not find too many difficulties to teach the concepts of OOA and OOD in the course of software
engineering, because the basic concepts and principles have been covered in the prerequisites of the software engineering course. I just need to put the concepts they have obtained to new notations and real projects. I believe that this benefit is coming from our course series. The real difficulties are still a mong the process of applying abstraction, i.e., how to form classes and their relationships from the real application. This situation is up to that the process of analysis . It is a very intelligent job that cannot be replaced by OOA and OOD tools and environments.
5. OTHER FACTORS To be successful in software education, there are many other factors that require us pay attention. • Concentrate on the properties of engineering SWE is an engineering discipline. We must be careful to teach students the required principles of engineering such as [5]: a. give products to customers early; b. evaluate design alternatives; c. use an appropriate process model; d. use different languages for different phases; e. minimize intellectual distance; f. put techniques before tools; g. get t h e progress right before making it faster; and h. accept the reality that people are the key to success and management is more important than technology. The products of SWE education are software engineers but not just programmers. A programmer writes source code. A software engineer writes the specifications and requirements for source code. It is actually very similar to the difference between a construction worker and a civil engineer. We, as SWE professors, should keep in mind that a software engineer is somebody who applies a formal or structured approach to the development of software. A software engineer should think about correctness, completeness, reusability and workability that match the end goal for the finished product. Software engineering focuses on development that is nondeterministic due to human involvement; is based on insufficient set of “laws” and “theories”; and requires more empirical observations to derive “software laws and theories”[12]. Even there are arguments for programming languages for computer science curriculum [2],
there are much more knowledge relevant to engineering to teach in SWE curriculum that more important than programming languages. • The basic requirements for a software engineering professor One of the most serious issues facing the software engineering education community is the lack of qualified professors to teach software engineering courses, particularly at the undergraduate level. Similarly, one of the most serious issues facing the software industry is the lack of qualified junior and senior software engineers. This shortage has existed for some time, and if it is not addressed properly will only worsen, thereby affecting the software engineering field in a more general way than it has already [11]. A SWE program hopes to teach students to deal with in the future large software projects with million lines of codes. However, these kinds of projects are not accessible to students [14]. Therefore, a qualified SWE professor should have some professional experiences. Professors should have been involved in large real software engineering projects. With these experiences, they could really offer what they obtained from realworld projects. With these experiences, the professors could really convince the students the real requirements of strict trainings in SWE. As an engineering discipline, there is much practical knowledge that is difficult to be put into a textbook. This kind of knowledge can only come from the professors’ personal experiences. A professor should also be able to know the state-of-arts of software engineering. Every year, to introduce 510% new contents into a software engineering course is required because SWE is developed very rapidly. A professor who teaches the contents of a text book published five years ago cannot be considered as successful. • Teaching abstraction ability Abstraction is fundamental to software engineering. From section 2, we know that senior students who have higher level of abstraction ability could understand and accept easily advanced knowledge in SWE. Based on Kramer, abstraction has to be taught indirectly and abstraction is teachable [9]. Just as what I discussed in section 2, we need to help students in the SWE discipline develop abstract abilities quickly in order to learn courses in SWE more easily. We should consider the natural law of cognition development of students and try to develop their abstraction abilities in our courses.
How could we teach abstraction? I can suggest methods as follows: a) Encourage students to learn enough mathematics; b) Introduce fundamental concepts with abstraction examples; c) Begin to teach students modeling and analysis from the introductory courses ; d) Teach simple design methodologies in early introductory courses [8]; e) Guide students to do simple abstraction to complex abstraction in their course assignments and projects; and f) Teach software engineering students how to use formal models as part of their software development processes. • Be careful to recurring concepts relevant to SWE a) Trade-off In software engineering, we should tell students that we cannot get something from nothing. For example, if we design a new program to save time, we must pay more in space or extra work on preparing data. If we hope to save spaces, we must pay more processing time. We should emphasize that tradeoffs among schedule, budget, functionality, staff and quality are very common in software engineering. Trade-off is an important recurring concept in the SWE curriculum. b) Ready for changing Software development is a time-consuming task that requires a long period to produce the final output. A typical behavior in projects is that new requirements are added at the rate of 1% per month [16]. It is common in the SDLC (Software Development Life Cycle) that the knowledge of the c lients about what the newly developed software product should be is gradually becoming clearer and clearer; at the same time, the budget and the time to deliver the product is gradually becoming less and less. This tells us a conceptual difference between the software development and the requirement analysis . The clients cannot describe completely what the newly developed software should be before they really use the software. When the product is released, could we guarantee that it is welcome by the market and the clients ? Even a project manager may tell you that “I don’t know precisely when we’ll finish — but I’m more likely to be able
to figure it out than anyone else in the organization. I promise that as soon as I have a more precise estimate, I’ll tell you right away” [16]. This demonstrates that it is common for a project schedule to change. We must prepare for chaining. Changing is a must and required for a newly developed software product [12]. Our students in the software engineering discipline must keep in mind this property firmly. Our student should know that a software product must be easily to be changed to meet the requirement changing from the clients and the market. That is why flexibility is a recurring concept in the SWE curriculum. c) The meaning of success What do we mean by success in developing a software product? In low lever programming courses, we can say that a project is successful if a program can run without errors and produce the results what the instructor ask for. However, we would better to teach students the general criteria for SWE as follows: • finishing on time; • staying within budget; • delivering the required functionality; and • providing “good enough” level of quality. In reality, there are many more empirical factors we need to tell the students, such as, good management, good documentation, liaison with the clients, and user training, etc. • Learning from our lives Many successful methodologies applied in SWE are common ideas in our normal lives. From the SWE history, it is a commonly accepted opinion that the best and practical algorithm or methodology is the first idea coming out from the brains of the software engineers. Some improved algorithms or methodologies are only required for special requirements or in special environments. As a SWE professor, we need to teach students to learn from our lives. Many intuitive ideas that seem trivial in our lives contribute a lot in the past software industry, such as client/server architecture, stack structures, and common scheduling algorithms of operating systems.
6. CONCLUSION SWE as an engineering discipline requires us to pay special considerations in teaching the relevant courses.
We need to make the software engineering courses easier for students to learn, and try to make software engineering education more practical and reflect the requirements of the industry . From the above discussions, we can summarize what we obtained from the experience in teaching SWE courses: • Abstraction is difficult to teach and it is a task all over the SWE discipline. • Some successful teaching methodologies [17] are only good for a special group of students. Students at different levels of have different level of understanding abilities. • Mastering the course material thoroughly is the fundamental requirement for a successful professor. However, this is not enough. There is also a requirement for professors to master the teaching methodology to convey their knowledge to students especially to first year students, because first year courses are more difficult to teach than the high level courses. Without this requirement, even you have all the knowledge, one might still not be considered as a successful professor. • Grouping relevant course into a series can save teaching resources; help students learn knowledge gradually; and ease the management of courses. • There many factors relevant to the experiences and the hard work of SWE professors. Nothing could replace the professors’ intelligences, experiences and dedications to be successful in teaching SWE cours es.
6.
7. 8.
9.
10.
11.
12.
13. 14.
References 1. 2.
3.
4. 5.
ACM/IEEE, “Computing Curricula 2001”, http://www.computer.org/education/cc2001/ Bruce, K. B. “Curriculum 2001 draft found lacking in programming languages”, ACM SIGPLAN Notices, vol. 35, No. 4, April 2000, pp. 26 - 28 Cooper, S., Dann, W. and Pausch, R., “Teaching objects -first in introductory computer science”, ACM SIGCSE Bulletin , Proc. of the 34th SIGCSE technical symposium on Computer science education, vol. 35 no. 1, Jan. 2003, pp. 191-195 Craik, F. I. M., The Nature of Explanation. Cambridge: Cambridge University Press, 1943 Davis, A.,M., “Fifteen Principles of Software Engineering”, IEEE Software, Nov./Dec. 1994, vol. 11, no., pp. 94-96,101
15.
16.
17.
Fischer, M., Demuth, B., Hussmann, H., “Experience in Early and Late Software Engineering Project Courses”, 15th Conference on Software Engineering Education and Training, Ottawa, Canada, Feb. 25-27, 2002 Gal-Ezer, J. and Harel, D., “What (else) should CS educators know?”, Communications of the ACM, vol. 41 no. 9 , September 1998, pp. 77-84 Ghafarian, A., “Teaching design effectively in the introductory programming courses”, The Journal of Computing in Small Colleges, vol. 16 no. 2, January 2001, pp. 203-210 Kramer, J. “Abstraction - Is it Teachable ?”, 16th Conference on Software Engineering Education and Training (CSEE&T 2003), Madrid, Spain , March 20-22, 2003 Liu, J., Marsaglia, J. and Olson, D., “Teaching software engineering to make students ready for the real world”, The Journal of Computing in Small Colleges, vol. 18 no. 2, Dec. 2002 Mead, N. R., Saiedian, H., Ruhe, G., and Bagert, D. J. , “Panel: Shortages of Qualified Software Engineering Faculty and Practitioners: Challenges in Breaking the Cycle”, 22nd International Conference on Software Engineering(ICSE’ 00), Limerick, Ireland, June 4-11, 2000 Rombach, D, “Teaching How to Engineer Software”, 16th Conference on Software Engineering Education and Training (CSEE&T 2003 ), Madrid, Spain , March 20-22, 2003 Shaw, M., “Software engineering education: a roadmap”, Proceedings of the Conference on the Future of Software Engineering, May 2000 Sitaraman, M., Feldman, M., Ford, G., Frakes, W., Hollingsworth, J., McAllister, D. and Weide, B., “Panel: What changes are needed for undergraduate CS curricula to educate ‘ software engineers?”, Proceedings of the conference on TRI-Ada'94 , Baltimore, USA, Nov. 1994 Stiller, E., LeBlanc, C, “Effective software engineering pedagogy”, The Journal of Computing in Small Colleges, vol. 17 no. 6, May 2002, pp. 124-134 Yourdon, E., “Preparing Software Engineers for the ‘real world’”, 15th Conference on Software Engineering Education and Training , Ottawa, Canada, Feb. 25-27, 2002 Zhu, H. and Zhou, M.C., “Methodology First and Language Second: A Way to Teach Object Oriented Programming”, Proceedings of the 2003 Educator’ s Symposium on Object-Oriented Programming, Systems, Languages and Applications (OOPSLA’ 03), California, USA, Oct., 2003, pp. 140-147
