2012 First International Workshop on Software Engineering Education Based on Real-World Experiences (EduRex)

Transcription

1 2012 First International Workshop on Software Engineering Education Based on Real-World Experiences (EduRex) IEEE Catalog Number: CFP1295S-ART ISBN: Copyright and Reprint Permission: Abstracting is permitted with credit to the source. Libraries are permitted to photocopy beyond the limit of U.S. copyright law for private use of patrons those articles in this volume that carry a code at the bottom of the first page, provided the per-copy fee indicated in the code is paid through Copyright Clearance Center, 222 Rosewood Drive, Danvers, MA For other copying, reprint or republication permission, write to IEEE Copyrights Manager, IEEE Operations Center, 445 Hoes Lane, P.O. Box 1331, Piscataway, NJ All rights reserved. Copyright c 2012 by the Institute of Electrical and Electronics Engineers Wolfgang Weck and Norbert Seyff Workshop Organizers Production: Conference Publishing Solutions, D Passau, Germany info@conference-publishing.com

2 Teaching Software Engineering with Projects Jochen Ludewig, Ivan Bogicevic Institute for Software Technology University of Stuttgart, Germany Abstract The software engineering curriculum offered by the University of Stuttgart emphasizes project work from the first to the last semester. While some of the projects are similar to those in other programs, others are less common. In this paper, we describe an introductory course called Program Understanding, and the so called Consulting Task. We also give a short description of what we call the First Software Project and the Large Software Project. In the Program Understanding course, new students learn to understand a fairly large, complex program in order to implement some modifications. In the Large Software Project, some ten people work on a serious software development for one year. In the Consulting Task, a group of three students analyses a problem, usually one given by an industrial partner. The students investigate possible solutions, and finally deliver a recommendation. Both our experience and feedback from students, including feedback from alumni, prove that these projects are very successful and highly esteemed. Keywords-software projects; Program Understanding; Consulting Task; software engineering curriculum I. INTRODUCTION Since 1996, the University of Stuttgart offers a software engineering curriculum [1]. After four years, the curriculum was evaluated and improved. The most important change was implemented in 2009 when the traditional Diploma curriculum (9 semesters) was replaced by a B.Sc. curriculum (6 semesters), which is followed by a M.Sc. curriculum (4 semesters). Most of the basic concepts, however, remained stable since 2000, including a gamut of projects throughout the curriculum. This paper describes two of the projects in detail (Program Understanding and Consulting Task), and gives an overview of two other projects in the undergraduate studies (First and Large Software Project). We are not aware of any other university where courses like Program Understanding and Consulting Task are offered. Since they turned out to be very successful, it might be interesting for colleagues who would like to add some industrial experience to their software engineering courses. II. GENERAL STRUCTURE OF THE CURRICULUM The software engineering curriculum at the University of Stuttgart is a computer science curriculum with emphasis on software engineering. Students collect 180 credits in six semesters. The courses given especially for the students in the software engineering curriculum are shown in table I. The table does neither show the courses not specific for software engineering students (like Introduction to Programming or Computer Architecture ) nor the bachelor s thesis. In Program Understanding and in the First Software Project, all participants work on the same problem, while for the Large Software Project and for the Consulting Task, every group is given an individual problem. TABLE I. SOFTWARE ENGINEERING COMPONENTS OF THE SOFTWARE ENGINEERING CURRICULUM Semester Course Credits Goals, description 1 Program Understanding 3 learning to read, understand, and modify a large program (lecture and exercises) 2 Software Engineering 6 lecture following a textbook on software engineering plus exercises 3 Program Development 6 lecture on programming in JAVA, including UML, plus exercises 3 First Software Project 6 complete software development from analysis to delivery, done in groups of three students, including a competition for the best solutions; often with a customer from industry 4 Advanced Software Engineering 6 lecture on selected topics of software engineering plus exercises 4+5 Large Software Project 24 a serious software development project done in a group of eight to twelve students for one year. The project includes a lecture and a seminar. 6 Consulting Task 6 a project about a (usually real) problem, often in industry, which is investigated by a group of three students /12/$31.00 c 2012 IEEE 25 EduRex 2012, Zurich, Switzerland

3 III. THE COURSE ON PROGRAM UNDERSTANDING Most programming courses follow a bottom-up approach, which could be called the Hello World paradigm. Students learn to use the constructs of some programming language, and start to write small programs. Large programs are not really treated; we rather tell the students that large programs are similar to small programs, except for their size and complexity; but we leave it to our students to understand that, in fact, large programs are very different from small ones. Large programs require many considerations that are less crucial for small programs, like good structure, useful comments, standards for naming variables and types, standardized comments etc. When we require our students to apply a style guide to their small exercises, they tend to object that they can easily solve those problems without such restrictions. And, to be honest, they are right. The traditional Introduction to Programming is still a mandatory course for all our new students, including students of computer science, software engineering, and mathematics. But for students of software engineering, we offer an additional course (3 credits), which concentrates on program understanding. New students learn to read, understand, and modify a large program. The course consists of a lecture and exercises. In the lecture, some basic concepts of software quality are introduced, like readability, and maintainability. But most important are the exercises. Three students form a team. At the beginning, all teams obtain the source code of an unfinished medium-sized application (15000 lines of code), written in ADA 1 by five different authors. It includes the source code of a large external library. This makes the code quite realistic. The application is a documentation tool for ADA programs, which automatically generates HTML documents from ADA source code, just like Doxygen does for JAVA programs. This program is then modified and extended in every exercise. Every team works on their own variant of the program all the time. The first exercises of the course are easy. A small feature (a hint that is shown when the input is incorrect) is added to the software; this modification is described in detail. Later on, we define what to implement rather than how to implement it. HTML files generated by the system are to be checked for validity. At the end, students have to refactor the code by externalizing language-dependent strings. Altogether, there are about fifteen such exercises, each of them requiring some 10 to 100 new lines of code. As the course proceeds, the modifications become more difficult. All the changes done before may put a burden on the actual task. Students learn soon that they have to apply standards, do some basic quality assurance, and write good code in order to maintain their comprehension. Since we introduced the course on Program Understanding, students did no longer protest against style guides and other rules. They know that they themselves are the ones who are harmed when the software is not sound, and well 1 In our university, ADA has been taught as the first programming language for many years. In autumn 2012, JAVA will replace ADA, and the course Program Understanding will be modified accordingly. documented. Since they work in teams, they also get their first lesson about the importance of regular and disciplined communication. They learn to use basic equipment like UML diagram designers and configuration management tools. We found that our students now do much better work in the 3 rd semester software project. IV. THE FIRST SOFTWARE PROJECT Our First Software Project is not that special: Teams of three students develop software during their 3 rd semester. All teams solve the same problem, which is (different from the task in the Large Software Project) fairly well defined. We try to find a real problem, with a real customer from outside. We also provide an internal customer, a Ph.D. student, because the external customer is not always available, and might ask for too much. There are several deadlines when the teams have to deliver documents, or demonstrate their solutions. Finally, there is a competition. The external customer becomes a sponsor, and the best teams receive a prize. One of the best solutions is usually adopted for permanent use (as in all the cases mentioned below). Every student should spend some 180 hours on this project (6 credits). A nice project was done for a mountain rescue organization that was looking for a better way to organize their press contacts. Our students developed a system for managing press notes and articles. As an internal customer, we once ordered a tool for project management, that has since been in use in all our projects. Recently, students developed a software for writing and managing Sprint notes. The customer was a company that has switched to Scrum, but was not satisfied with using standard office software for their project documentation. V. THE LARGE SOFTWARE PROJECT A. Concepts of the Large Software Project In order to experience both the difficulties and, far more important, the chances of real software projects, participants should work on a real problem, not on a toy problem. They develop a large, and complex, software system. Eight to twelve students are accepted in every project. The project should be finished after ten or eleven months; every student contributes 450 hours, earning 15 credits. We start with three or four subgroups that act as competitors. After requirements elicitation, every team delivers a tender. The customer will choose one or a mixture of two or three. Then, the students merge into one software house. They elect, or agree upon, a project manager. His or her task turns out to be difficult. There are conflicts and other problems until the participants have learned that far more discipline is needed than in their previous projects. The (internal or external) customer behaves like most customers: Changing ones mind, adding requirements, and answering questions vaguely is a normal customer s behavior. There are also supervisors who check the progress and blow the whistle when the project is about to fail. But usually, they do not interact, except when the students ask them for help. 26

4 The project work is complemented by a lecture and a seminar. In the lecture, the students obtain some background knowledge, e. g. they learn the basics of visualization when they do a visualization project. In the seminar, they usually cover the technology that is applied in the project. B. The Development Process We provide some basic resources, like a room and all the tools appropriate for the project. Everything else is left to the students. They usually choose a fairly traditional process, some variation of the waterfall model. We found that two cycles are most appropriate in most projects. The first cycle delivers a very basic system after about seven months. depending on the customer s judgment, the remaining time can be used to improve the system, and to add missing parts. C. Examples In 2007, a tool for glass box testing was developed, also known as white box testing. We asked the participating students to agree with a contract that all the results would be freely available in the public domain. (By default, any software that the students develop is their property.) The system they built was not really complete for immediate use, but worked very well. It was later extended and polished with fairly limited effort. Now it is widely used [2], [3]. In 2008, a project was launched for developing a conference system. Since the software was intended to be used in a conference about half a year after project start, the students were under strong pressure, and failed to deliver a useful system that soon. But after what they considered to be a complete failure, they used the remaining time to finish their software, which was then used for two conferences. Though research is not part of our Large Software Projects, many deliver tools for research projects, like projects in robotics and even in theoretical computer science. VI. THE CONSULTING TASK A. Background Engineers in industry cannot just work on solutions, like writing specifications, or implementing a program. They often have to take decisions: Should we switch to a more powerful (and more complex) tool for software configuration management? or Is Scrum an attractive approach for our projects? According to our experience, students love to work on solutions, even if they have to write specifications, but they hate to take decisions. Even if they write a thesis on a comparison of a range of tools, they will usually end up with a statement like Any tool has some advantages and disadvantages. In a Consulting Task, the students are required to take a decision. There is a customer, usually somebody in industry, and the customer needs a clear recommendation: Do this or do that. There is no compromise. In most cases, the customer will follow the recommendation, that means: Our students deal with real effort and real money, just as they will do more frequently when they have left the university. But as students, they can contact their supervisor, and they will get feedback, allowing them to improve their approach. Software development is strictly forbidden in a Consulting Task, except for small programs required for the evaluation of tools and similar purposes. B. The Consulting Task Process Three students form a group for a Consulting Task. They talk to faculty members who have projects with industry, so they know of problems that could be dealt with in a Consulting Task. When the students have found a task they like, they sign a contract. Under the guidance of their supervisor, the students choose their approach, set up a project plan, and read any useful material. They meet their partners in industry, trying to understand the problem well. Depending on the task, they may set up a questionnaire, meet people who answer the questionnaire, and evaluate the results. Or they may find some tools, do some experiments with the tools, and check them against the requirements. Finally, they write a report, in which they state clearly their recommendation. They also deliver a presentation on their results. During the project, which is limited to six months, the students will see their supervisor in regular intervals. They also give a presentation when they are about half way through, allowing for hints and corrections. There is neither an examination nor a mark, the group can only pass or fail as a whole. The decision is taken by the supervisor, usually together with the responsible professor. Failures are, however, extremely rare. The students experience a new, and very special challenge when they meet people in industry who accept them as experts. Our industrial partners appreciate the systematic approach and the well documented rational for the recommendation. They also know that we supervise the students. In many cases, the students are offered jobs after delivering their results. C. Examples of Consulting Tasks 1) Runtime Platform for Mobile Devices: A local software house developed mobile applications for an insurance company, for historical reasons in.net. All other software was developed in JAVA. Furthermore, performance and usability were hardly acceptable. Their question was: Should we switch from.net to JAVA? If we do, how will the application s performance and its user interface change? What other platforms should we consider? The students analyzed the current situation in the company. They interviewed employees, read documentation and source code, and scanned the literature for suitable platforms. They identified and rated twelve configurations, including three.net and four JAVA solutions. They installed the top four configurations on a mobile device and checked performance and user interface. They also tested the corresponding development environments. The final conclusion was: Stay with.net, but use a different version. A recommendation for the migration process was included. The software house accepted the results, and reported a successful transition a couple of months after. 27

5 2) Evaluation of Extreme Programming: A software house was interested in an evaluation of agile methods, in particular XP, for their projects. The students studied both the agile literature and the processes in the software house. They found that the actual process worked very well, and that the software house would not benefit from agile ideas. But they recommended pair programming in certain situations, in particular for the training of new employees. 3) Preparation for CMMI: In a similar project, students investigated the cost and benefit of a CMMI appraisal for a company that is highly specialized in software for transport systems. They found out which criteria of CMMI level 2 were already satisfied, and how much effort was necessary to achieve a level 2 certificate. The company found that they were sufficiently close to level 2, and postponed any further activities in CMMI. 4) Continuous Integration and Deployment Tools: The IT department of an international company for medical and healthcare products develops in-house software. Since integration and deployment was done more or less by hand, it caused high cost in terms of time and effort. The students investigated the actual process of compiling, integrating, and deploying the software, and analyzed its structure. They searched the web for suitable solutions, and they found 28 tools. These were evaluated with respect to the requirements and the status quo. The top three tools were procured and tested on-site with real project data. The champion was purchased and is now in use. As expected, it saves much time and effort every day. D. What is so Special with the Consulting Tasks? So far, some 150 Consulting Tasks have been carried out. When we ask the students after the projects what they liked best, they mention constructive teamwork, useful weekly meetings, great mutual trust between company and students, and satisfaction for being accepted as experts. After dozens of such projects in our group, we can say: The students like it, and the companies like it even more. We like it, because we strengthen our contacts to industry. In the beginning, we have to strengthen the students self confidence, and to push them towards the industrial partners. When they have learned that their help is appreciated, they are well motivated by themselves. They overcome their fear of decisions, because they arrive at their recommendation only after a careful investigation and a rational decision process. We are not aware of any other project with a similar return on investment. VII. OBSERVATIONS AND CONCLUSION Colleagues from other universities often ask how we can provide solutions for the problems we give to the students. The answer is very simple: We don t. The idea that the teacher knows what the answer is does not fit our view of software engineering. When we start a project, we are sure that there is a solution. That is enough. While we sometimes receive software that is hardly acceptable, some of our students deliver software that goes well beyond our imagination. We always want them to collect data on their work load, and working overtime for extended periods is not considered as good practice. Final success is not guaranteed. But we do our best to let them succeed, because positive experience will boost their self-confidence to deliver good software engineering after graduation, even in a hostile environment. A serious problem is the lack of understanding good software engineering in other groups of our department. While Program Understanding and the First Software Project are under our (i.e. the software engineering group s) control, the Large Software Projects and the Consulting Tasks are issued by all professors in our department. We sometimes hear from students that not all environments are really software engineering friendly. When the students write specifications, or spend time on reviews, they may be criticized for wasting time that could (and should) be used for making progress. All we can tell them is that this is a perfect preparation for life in industry, where they will experience similar conflicts frequently. Our projects would not be possible without our Ph.D. students, who are in Germany usually employed as teaching assistants for five or six years. They do most of the work, supervise the students, check the results, and eventually pass their know-how on to their successors. Though our students often complain about the amount of work they have to do, most of them like the projects. A recent national study (50 universities) of the alumni s satisfaction with their curriculum showed that our software engineering curriculum is well above average [4]. Our projects are the top reason for this result. ( Former students of Software Engineering in Stuttgart gave a particularly high rating for the projects in their curriculum. ) ACKNOWLEDGMENTS Markus Knauß initially designed and run the Program Understanding course. We appreciate the comments in two anonymous reviews, one of which was very detailed. REFERENCES [1] J. Ludewig, Software Engineering at Full Scale in H.J.C. Ellis, S.A. Demurjian, J.F. Naveda (eds.): Software Engineering Effective Teaching and Learning Approaches and Practices. IGI Global, Hershey PA, USA. Chapter XIV, , [2] S. Kleuker, Werkzeuge zur Qualitätssicherung in der Software- Engineering Ausbildung (Tools for quality assurance in software engineering education; in German) In: U. Jaeger, K. Schneider (eds.): Software Engineering im Unterricht der Hochschulen (SEUH). dpunkt.verlag, Heidelberg, [3] N. Koochakzadeh, V. Garousi, F. Maurer, Test Redundancy Measurement Based on Coverage Information: Evaluations and Lessons Learned In Proceedings of the International Conference on Software Testing Verification and Validation (ICST '09). IEEE Computer Society, Washington, DC, USA, [4] Stabsstelle Qualitätsentwicklung der Universität Stuttgart, Studienqualität im Rückblick. Absolventenstudie der Universität Stuttgart, Überblick über die Abschlussjahrgänge 2008 und 2009 der Fakultät Informatik, Elektrotechnik und Informationstechnik (Office for Quality Development of the University of Stuttgart: A retrospective on the quality of studies. A survey of graduates in 2008 and 2009 in the department of Computer Science, Electrical Engineering and Information Technology; in German)