The Software Engineering Profile at Umeå University

Transcription

1 from: Proceedings ISSEU 97, The First International Symposium on Software Engineering in Universities, Rovaniemi, Finland, The Software Engineering Profile at Umeå University J. Börstler Department of Computing Science, Umeå University, S Umeå, Sweden jubo@cs.umu.se Abstract This paper describes the software engineering profile at Umeå University. In particular it discusses the organization of a series of practical project-oriented courses. In software engineering education practical courses are very important, since many aspects of this discipline cannot be taught adequately in traditional classroom lectures. In an experience section the paper describes the critical elements to make a students project a success, namely support for project management, selection of the right type of project, and selection of the right tools. 1 Introduction During the last three years the Department of Computing Science at Umeå University, Sweden successively reorganized its course structure towards a stronger Software Engineering profile. Besides the Software Engineering profile our department provides profiles in Cognitive Science, Parallel Computing, and Scientific Computing. The Software Engineering profile covers the following three aspects of software engineering: Theoretical background in creation, handling, and analysis of software; The study of well-known application domains; Practical application of the principles in team oriented projects. Especially the last point is very important in Software Engineering education. Software engineering is a discipline which evolved to cope with the complexity of large software systems and their production. But approaches to cope with complexity are difficult to teach in classroom lessons alone for mainly two reasons. First there are almost no useful examples. During traditional lectures most software engineering methods and techniques appear to be trivial, since there is not enough time to introduce complex examples. Small exercises or assignments do not help either, since the real value of software engineering does not proof itself

2 to be useful for them. The application of software engineering methods and techniques rather seem to be counterproductive in causing the production of a lot of superfluous documents. The second problem is to teach the importance of communication and teamwork. Without doing any real teamwork this is very difficult. A deeper understanding of software engineering can therefore only be gained by practical experiences ([1], [2]). The reminder of the paper is organized as follows. Section 2 gives an overview over the software engineering profile at Umeå University. Section 3 describes the outlines of the main (project-oriented) courses in the profile. Experiences with these courses are discussed in section 4. Section 5 concludes the paper. 2 Profile Overview Figure 1 gives an overview over the course structure for the relevant courses. The students start with courses on Mathematics followed by a sequence of introductory Computing Science courses (PM, CS1, and DA). These first year courses have been recently redesigned to more deeply cover systematic program development (PM) and basic theoretical computer science (CS1). We found it very important to teach some theoretical background already during the first year. We see it as very important for the students to understand the computational power of computers as well as its limitations. The lessons on systematic program development stress the importance of abstraction and information hiding, the usage of assertions, and ab- CC1 AA CC2 OS CSA PM CS1 DA CSB SP SE HCI SC1 compulsory courses (first and second year) SC2 CS2 DB OOSE SPT PSC SEC optional SE profile courses (third and fourth year) Figure 1: Course structure of our Software Engineering profile (computing science courses only).

3 stract data types. CSA is accompanied by a series of assignments, which range from simple in-lab exercises to complete programs. All assignments, but the simplest ones have to be submitted together with a complete documentation. During the second year the students take courses on Systems Programming (SP), Scientific Computing (SC1/2), Human-Computer Interaction (HCI), and Software Engineering (SE). SE splits into a traditional part and a project oriented part. It focuses on structured techniques and will be discussed in more detail in section 2.1. Furthermore students have some more maths courses and a course on Logic, Logic Programming and Computability (CS2). The first year and second year courses are compulsory for all students in our Computing Science programme. During their third and fourth year the students can specialize in several areas. In the software engineering profile we provide courses on Compiler Construction (CC1/2), Algorithm Analysis (AA), Operating Systems (OS), Databases (DB), Object-Oriented Software Engineering (OOSE), Semantics and Program Theory (SPT), Program Specification and Construction (PSC), and a conference like seminar (SEC). In the sequel of the paper we will focus on the core software engineering courses of the profile, that means SE, OOSE, and SEC. All of these courses have in common that they are practical courses. They are oriented towards concrete projects and consist of traditional lectures, formal (group) meetings, and presentations. All courses require more or less extensive documentation. 3 Courses outlines Our software engineering courses should be seen as a series of courses experiencing all software engineering related activities. Apart from the traditional software life-cycle oriented activities this includes project management, team dynamics, and the presentation of results and ongoing work. The SE and OOSE courses are geared towards practical software development, whereas the SEC course is geared towards research, that means it focuses on technical writing and presentation. In all courses the world wide web is used as a platform for information exchange. 3.1 The Basic Software Engineering Course SE is taught in two parts. Part one consists of traditional lectures, exercises, assignments, and a written exam. The second part of the course is team project oriented. See table 1 for the details of the course structure.

4 The goal of the course is to give students an introduction to the theory and practice of the software development process and all activities related to the development of large (software) projects ([3], [4]). The main purpose of the project part is to let the students experience that working in teams really adds another dimension to software development. To make things as realistic as possible, we have chosen a two-stage team structure, where each team itself is a member of a bigger team. In this project the students realize the importance of well-designed interfaces and reliable components. We think that this is a very important lesson. Students completely unexperienced in teamwork may experience big problems, when they join a big team for the first time. They realize that they do not have full control over the whole project and depend on others to fulfil an assigned task. week lecture topics assignments exercises project lectures: Software Life-Cycle Software Quality Project Planning Requirem Engineering 3 lectures: Requirem Engineering User Interface Design Software Design 2 lectures: Software Design Quality Assurance 2 lectures: Testing Version Control Project Management Structured Analysis 1 exercise: Lectures exercise: Lectures exercises: Lectures 7 9 Introduction 5 examination GUI design 6 GUI selection Group restructuring 7 Development 8 Development 9 Development 10 Final Presentations Prototype Demos Final Report Table 1: Structure of the basic Software Engineering (SE) course

5 The project part is subdivided into a graphical user interface (GUI) design part and a product prototyping part. For the GUI part the students form teams of 3 or 4 students and use a commercial GUI builder to develop a GUI prototype. From these prototypes we select some for further development. The teams are then grouped into larger teams to build a running prototype using the selected GUI as its interface. A teacher or teaching assistant is assigned to each main team to ensure that the project does not get out of control. All teams run the same project, that means that the teams compete against each other for the best results. This leads to interesting and very lively final presentations. Our two-stage team structure makes project organization very difficult. We therefore select a simple project to reduce the technical problems to a minimum. Simple in this case means that the problem is clearly defined and the problem domain is well-known to the students. Since the project part spans only 6 weeks the requirements engineering and architectural design phases are mainly left to the teachers and teaching assistants. 3.2 The Object-Oriented Software Engineering Course The OOSE course focuses on object-oriented analysis and design ([5]) and builds on the SE course described before. OOSE is a team project oriented course (see [6]) and strongly oriented towards the deliverables the students teams have to produce. See table 2 for the details of the course structure. Each team consists of 4 to 6 students and runs a whole project from the developement of a project plan to the presentation of a running prototype. Each team member fulfils the roles of one or more specialists, for example team manager, requirements specialist, an so on. The roles define responsibilities for one or more deliverables and/or presentations. This gives the lecturer some means to control that all students in a team do some work. During the project each team acts as a customer, as a contractor, and as a subcontractor. As a customer it proposes a project for selection by the other teams. During the requirements engineering phase the proposing team then has to negotiate requirements with a contracting team (the contractor). A team must not contract its own proposal. We introduced this restriction since students usually have big problems writing down requirements for their own ideas. In their heads most of the things are crystal clear. They therefore tend to produce incomplete requirements documents which are difficult to understand for others. During the project each team must subcontract another team for a small part of the prototype implementation. To do this each team designates a well-defined part of its design and

6 provides it with black-box test cases. These parts have then to be subcontracted by another team for implementation. This (again) confronts the teams with the importance of fixed and clear interfaces. This part is still not working perfectly due to the freedom we allow in choosing languages, tools, and application domains. It does therefore sometimes occur that there are no teams available, which are able to do the subcontracting. In the few cases this happened we allowed the teams to subcontract their own parts. Finally we require that each team evaluates another teams prototype to motivate the production of a user manual and to assist the lecturer in project evaluation. week lecture topics project deliverables due 1 2 lectures: Repetition Object-Oriented Analysis (OOA) Team Descriptions Project Proposals 2 Oral presentations of teams and proposals OOA continued 3 Example continued Object-Oriented Design Example continued Subtyping vs Inheritance Another Example More Inheritance Frameworks Design Heuristics Project Plans Requirements Documents Oral presentations of projects analysis and designs Design Heuristics continued Design Patterns Design Documents Test Plans Subcontracting Information Prototype User Manuals Prototype Demonstrations 10 Prototype Evaluations 11 Final Reports Table 2: Structure of the Object Oriented Software Engineering (OOSE) course. To ensure that useful proposals are available students teams are not required to take another teams proposal for the remainder of the course. They may also contract projects proposed by the teacher or teaching assistants of the course. To make the courses projects even more realistic, we are currently running two projects proposed by regional companies.

7 3.3 The Conference Course This course was designed to stimulate research and to improve the writing and presentation skills of our students. To make this course as attractive as possible we run it as a conference to give students a forum, where they can actively participate in research. The course is a practical course for those students interested in research and introduces students to independently researching an interesting topic, writing a scientific report on their work, and presenting their work at a conference. The course is open to all students with at least one successfully completed course in the computing sciences. This will hopefully give the course an interdisciplinary character. week 1 Course Introduction: Researching a topic 2 Writing a paper Giving talks 3 Preparation of contributions 4 Evaluation of contributions scheduled activity Extended Abstracts due 5 Notification of Acceptance 6 7 Preparation of final paper 8 9 Final Papers due 10 Preparation P of ftalks and posterst Publishing of proceedings 11 The Conference 4 Experiences Table 3: Schedule for the Conference Course (SEC). Participation had been about 40 students in the SE course and about 18 students in the OOSE course for the last three years. Due to some reorganization of our courses and increasing popularity participation has increased considerably for the fall 96 term (80 and 40 students resp). According to our experiences there are three critical elements for the success of a project oriented software engineering course: project management project type

8 tool support Since the SEC course will be taught in spring 97 for the first time, we can only discuss experiences from the SE and OOSE courses in this section. 4.1 Project Management Our experiences show that students have a lot of difficulties with project planning and intra- as well as inter-team communication. In our first SE project we did a library project with a graphical user interface. Since the user interface depends on most of the other parts of the system we assigned the user interface groups some of the project management tasks. This turned out to be a bad decision. It ended up with a very heavy work-load for these groups, since other groups where unwilling to help in parts integration. In the SE course project management is therefore mainly done by the lecturers to avoid a too uneven work load between groups. In addition we introduced an assignment into the traditional part to do project scheduling for the actual project to be run in the project part. In the OOSE course each team must produce a project plan (mainly consisting of project scheduling) as an early deliverable. Minutes of all team meetings have to be included into the final report to get some control over the decisions made, actual work distribution, etc. This has the effect that students take planning and communication quite seriously. It is our believe that planning and communication are impossible to teach in the classroom alone. Without project orientation there is no chance for the students to even recognize that these are one of the biggest problems in team projects. 4.2 Project Type Up to now we tested the following kinds of projects: Different kinds of editors, inventory systems, accounting systems, simulations, and die games, and an internet-based robot. Inventory and accounting systems are proposed very often as good examples for students projects. According to our experiences they are not very well-suited for courses on object-oriented analysis and design. Their basic architectures are too simple. They mainly consist of a simple database to keep track of some kinds of stocks or states of accounts and a user interface component. There usually is no real processing logic, or object behavior. Often the systems are simply some kind of data entry and viewing system. But object behavior modeling is a very important aspect of object-oriented analysis and design (independent of the actual method used). Therefore behavior modeling cannot be taught adequately in such

9 inventory and accounting systems. The application of use case analysis, scenario modeling, state transition diagrams, etc. is usually not needed to model the systems behavior. The students therefore avoid the usage of these techniques, since they only add complexity to the analysis and design phase. The other types of projects offer much more opportunities for behavior modeling, like for example the modeling of the rules of a game or the complex interactions of simulated (real world) objects. Games and simulations have two additional advantages. First the problems are easy to understand and it is very easy to convince students that requirements may change. You can very easily play through scenarios that show the effects of changing requirements. A very good example is to change the number and types of dice in a game. In doing so students can experience the importance of design, the planning for change, and reusability. Second and not less important, games and simulations are more fun to produce. 4.3 Tool Support Tools are very important for two reasons. First the students should be enabled to concentrate on the problem instead of wasting their time with the drawing of diagrams. And second the students should get a feeling for the type of tool they might use in industry. The problem with tool support is that there exist vast amounts of tools for every single step in a project, but these tools do not work smoothly together. What is needed is an integrated toolkit, which supports all basic software development activities, starting with project scheduling down to test case development, the edit-compile-debug cycle, version control, and documentation generation. The SE projects run under UNIX and C/C++ and we provide the students with an edit-compile-debug environment and a GUI toolkit. The students already know C and the edit-compile-debug environment from previous courses. Knowledge in C++ is advantageous, since the GUI toolkit generates C++ code. In the OOSE course the students may choose platform, language, and tools freely. The notation for doing analysis and design however is fixed ([5]) and a tool is provided to support object-oriented analysis and design. In both courses WWW and are heavily used for communication and distribution of information. 5 Conclusions The software engineering profile at Umeå University give a broad introduction to theory and practice of software development. Students run non-trivial team-oriented projects in their second and third year.

10 In our opinion such courses are needed, since several important topics cannot be taught in the classroom alone, like project management, coping with complexity, and working in teams. Although most of the students like how the SE and OOSE courses are organized, there are some recurring complaints. These are too tight schedules, too much programming, and we need better tools, and all of them are justifiable. The projects actually have tight schedules, but this is necessary to embed them into our existing overall course structure. That the projects consist of a lot of programming is correct too. The students often add to their complaints that they do not need another programming course, but would like to concentrate on analysis and design. In our opinion programming and testing are necessary to proof a designs quality and if it is implementable at all. Without programming the degree of freedom during design is too big and design decisions do not have any disastrous consequences for the coding phase. In both courses the students may use languages, which are not part of the courses prerequisites. Doing so had pragmatic reasons. In the SE course we did not find any GUI toolkit generating C and could not install the preferred one for Pascal (due to platform problems, but this will be better next year). In the OOSE course students may choose languages almost freely and therefore often test something new, like for example Java. That better tool are needed do we all know. Unfortunately this is not only a question of availability, but also of pricing. Most project management tools or integrated environments are simply far too expensive for educational purposes. References [1] M. Moore, C. Potts, Learning by Doing: Goals and Experiences of Two Software Engineering Project Courses, Technical Report, Georgia Institute of Technology, [2] B.T. Mynatt, Software Engineering with Student Project Guidance, Prentice-Hall, [3] R. S. Pressman, Software Engineering, A Practitioner s Approach, European edition, McGraw-Hill, [4] W. S. Humphrey, A Discipline for Software Engineering, Addison-Wesley, [5] G. Booch, Object-Oriented Analysis and Design, with Applications, 2nd ed., Benjamin/Cummings, [6] J. Börstler, Experiences from a Project Oriented Software Engineering Course, Technical Report UMINF 95.27, Umeå University, Umeå, Sweden, 1995.