The Personal Software Process in Undergraduate
Software Engineering Education
A.L. Brown, M.J. Oudshoorn and K.J. Maciunas
Department of Computer Science
The University of Adelaide
Adelaide SA 5005
Australia
E-mail: {fred, michael, kevin}@cs.adelaide.edu.au
Abstract
The Personal Software Process, PSP, was developed at Carnegie Mellon University’s Software Engineering Institute as a personal version of the Capability Maturity Model. The intention of the PSP is to educate individual software engineers in the processes they follow in completing a programming task with a view to improving the quality of future work. At each level of the PSP more and more useful personal statistics are kept. This starts with simple time keeping and error reporting statistics, and is later augmented by recording code size and self-improvement plans. At its deepest level, the process involves evolving a personalised version of the PSP. It is esti-mated to take 400 hours to complete the entire PSP course at the graduate level. Clearly, this would impose an extreme burden on an undergraduate curriculum if it was taught as a whole. Indeed the PSP is aimed at practising software engineers and in its more sophisticated forms would be beyond the scope of an undergraduate degree. This paper discusses how elements of the PSP can be introduced in small incremental steps into an undergraduate curriculum without compromising the existing course content, how this can improve the quality of the teaching and, in turn, how this can improve the quality of a student’s learning experience.
1
Software Engineering Education ñ Current Practices
The Department of Computer Science at the University of Adelaide teaches a relatively ìstandardî computer science curriculum. Space within the curriculum is at a premium and there is virtually no scope in the curriculum for the addi-tion of extra subjects unless existing course material is either compacted or re-moved. Within these severe constraints, we have developed a vertically inte-grated software engineering stream which is reasonably successful.
1.1
Philosophy
The philosophy used to bring focus on software engineering issues is both practical and pragmatic. Concepts are reinforced through programming as-signments designed to give students exposure to appropriate issues and to pro-vide them with relevant experience in software design and coding. This com-mences in the studentsí first year where they are introduced to programming skills and issues relating to programming-in-the small, through to their final year where they are engaged in a group-based project addressing issues relating to programming-in-the-large.
Since all existing courses already have programming, it is almost cost-free to ensure that students follow a process (apart from the incremental cost of teaching the process). We have introduced aspects of the Personal Software Process [4,5], PSP, which was developed at the Carnegie Mellon University’s Software Engineering Institute as a personalised version of the Capability Ma-turity Model [9]. The intention of the PSP is to educate software engineers about the processes which they follow when completing a programming task with a view to improving the quality of future work. Such an ideal is precisely what educators wish to instil into students as they learn how to program.
1.2
Structure
With the exception of one final year subject, Software Engineering and
Proj-ect, there are no subjects dedicated to software engineering with the curriculum
at the University of Adelaide. It is our view that there is no need to place undue emphasis on the notion of software engineering, instead, it is a crucial compo-nent of all of the programming related subjects taught within the curriculum. The intention being that students gradually learn to apply software engineering discipline as necessary throughout the degree course. The programming sub-jects are just a small part of the usual computer science curriculum which in-cludes the usual spread of subjects ranging from Artificial Intelligence to
Op-erating Systems and Compiler Construction. The subjects which are of interest
here are those whose key activity is programming. These subjects and their re-lationship are shown in Figure 1. As can be seen there are only five subjects which make up the software engineering/programming thread of the degree programme. Other subjects have programming exercises and they represent an opportunity to have students continue to apply their programming skills and processes.
The subject Computer Science 1 is an introductory level subject and as-sumes no computing background. Over the course of the year students are in-troduced to basic programming and design techniques [2]. The course empha-sises structured design of systems and introduces sound software engineering practices which forms the foundation of future material delivered in later sub-jects. On completion, students are expected to be able to apply the concepts of sound design, clear expression and documentation.
The level-2 subject Data Structures and Algorithms aims to further de-velop the students’ skills in programming-in-the-small. It is a standard data structures course with emphasis on time complexity and software reuse [3]. The benefits of good design are reinforced with a corresponding increase in student productivity.
Programming Paradigms is a course which expose students to a range of
programming languages and methodologies (imperative, functional, logic and object-oriented). The course concentrates on design methods rather than spe-cific programming languages. Programming exercises are designed to broaden the students’ perspective.
By the time students commence their final year of study, level-3, they are well versed in programming-in-the-small and appropriate methodologies to de-sign programs of a few hundred lines. The subject Programming Techniques, extends the students repertoire of data structures and encourages them to think about the application data structures and algorithms in order to solve problems [1]. Students are expected to demonstrate thorough testing, an awareness of complexity issues and an ability to assess their own work.
Software Engineering and Project is the final subject in the software
en-gineering thread. It is a practically oriented course with a major assessable component being a group-based programming project [6,7,8]. In this course, students are set a task (e.g., control a model rail system) which is beyond the ability of even the best individual in the class and can only be solved through teamwork. All of the software engineering skills acquired by the students in preceding courses are needed and adherence to sound processes is essential. Students are encouraged to perform code walk-throughs and inspections within their project groups. The exposure to colleagues’ coding practices provides re-inforcement for the need for processes and software engineering principles.
1.3
Critique
The software engineering thread discussed above provides a strong focus to the undergraduate degree programme. Students gain an appreciation for issues re-lating to programming-in-the-small; techniques and methodologies; and pro-gramming-in-the-large. Software engineering issues are dealt with implicitly rather than making software engineering appear out of the ordinary. However,
Level 1 Programming methodologies Programming in the small Programming in the large Level 2 Level 3 Computer Science 1
Data Structures and Algorithms Programming Paradigms Software Engineering and Project Programming Techniques
despite the efforts to encourage students to follow a defined and disciplined process in the design and development of code, we have failed to meet our own expectations. Feedback from industry has also helped to identify weaknesses in the students’ abilities. These shortcomings are essentially:
1. lack of appreciation of company profit margins and the need to deliver correct code on time and within budget,
2. lack of experience in cost estimation, including the length of time re-quired to complete a task, and
3. varied personal productivity.
In addition, a number of problems are encountered and identified by the students as weaknesses at the time of their graduation. These include:
1. poor timekeeping skills,
2. a perception of being over worked,
3. a perception of insufficient laboratory resources, 4. a lack of appreciation of testing, and
5. inadequate design skills.
In addition, we wish to address problems encountered by teaching staff such as:
1. the difficulty of monitoring student performance,
2. the difficulty of giving prompt and relevant feedback to students, and 3. the difficulty of tuning the practical work to actual student abilities.
2
The Personal Software Process
The Personal Software Process, PSP, is designed to address many of these con-cerns. In its most elementary form, the PSP involves logging time spent on the various aspects of programming, and logging the kinds of defects found as well as where and when they are found. In its most sophisticated form, it involves tailoring the PSP to suit each individual.
Timekeeping is a task the majority of students find difficult. Some at-tempts to solve this problem rely on setting staged deadlines for practical work so that the students start earlier. However, this only addresses a symptom, not the cause. The underlying cause of the problem is that students are largely un-aware of how long even apparently simple programming tasks will actually take. The PSP can be used to address this problem since it requires the students both to estimate and then record the actual time taken on each practical.
Perception of workload is related to that of timekeeping. Since most stu-dents do not realise how long they need to spend on practical work, they tend to think they must be being overworked. For the weaker students this may be true but for the majority it is simply that, in comparison with some other subjects, software engineering is more practically oriented. Through using the PSP to teach students how much work is actually required of them and how this relates to their total workload, students will be able to objectively assess their own workloads.
Any lack of available laboratory resources is a further consequence of poor student timekeeping and planning. All our laboratories can accommodate every student spending the requisite amount of time on all their subjects within normal working hours. Unfortunately, students rarely start their work e arly enough resulting in overloading laboratories as practical deadlines approach. If the PSP can teach the students that they need to start earlier the peak laboratory
load should decrease significantly. Improved personal productivity achievable using the PSP should also further reduce the total laboratory load.
Testing is a vital part of any software engineering exercise. Students have very little grasp of its importance due in a large part to the fact that they are rarely expected to demonstrate such skills. An essential part of the PSP is re-cording all errors made, when they occurred, when they were fixed and how long they took to fix. A clear understanding of how and when errors occur, and their impact on how long a project takes, encourages students to address their main areas of weakness. This needs to be reinforced by giving increased weight to the correct functioning of practical work in the presence of probing tests.
Poor design skills appear to arise because most practicals are relatively small and obvious. This problem can be addressed by a student assessing their pattern of mistakes which can be collated from the PSP data. The relative cost of fixing errors made at the design stage will rapidly become apparent, result-ing in more attention to the design phase. In turn, the extra time spent on design should provide enough practise to improve a student’s design skills.
From the teaching staff’s perspective, employing the PSP with the sup-port of software tools will allow the PSP statistics for each student to be col-lated into a class-wide database. These software tools, which are yet to be written, will replace the excel spreadsheets used with the PSP [5] and be capa-ble of handling 1,000 students in any given calendar year. This will give the teaching staff the ability to monitor time keeping and error trends during practi-cal work rather than during the marking process. It is anticipated that many forms of common errors will be highlighted by the collated data and appropri-ate advice can immediappropri-ately be provided to students. Any shortcomings in time keeping should also be obvious allowing appropriate encouragement and ad-vice to be given before it is too late. Finally, collated time keeping information will allow staff to also learn how long it takes students to complete the work that is set. This learning experience should tune future expectations of students to more realistic levels.
Industry concerns regarding the delivery of correct code, on time and within budget are also addressed by the PSP. Students learn to accurately esti-mate the length of time required to develop code. Common programming errors are made obvious to the students through the process and students learn not to make these mistakes thereby improving their productivity and the quality of the code delivered.
It appears that the PSP has much to offer in terms of improvement of the students’ performance, and goes a long way to address the concerns of the teaching staff and potential employers, as well as concerns expressed by the graduating students.
3
Incorporating the PSP
Wholesale changes to the undergraduate curriculum carry an element of risk. In order to minimise this risk and verify that the proposed changes are indeed beneficial to the students and staff, the PSP was introduced to a limited number of subjects in 1996. These subjects include Computer Science I, Programming
Techniques and a special subject called Introduction to Software Engineering
which is only available to students undertaking a full-time one-year Postgradu-ate Diploma in Computer Science. The PostgraduPostgradu-ate Diploma is only available
to students who already hold a degree in another discipline and wish to gain the equivalent of a major in computer science; it makes no assumptions about the computing background of the students.
Introducing the PSP to the undergraduate curriculum need not require a significant change to the content of most courses. Much of the basic PSP mate-rial is already taught in one form or another, distributed through out our soft-ware engineering stream. By adopting the PSP, these sometimes disjoint threads can be integrated into a clear overall plan. The availability of a textbook describing the PSP should encourage students to treat it is an important part of their education. All that is then required is to expect students to follow the ap-propriate level of the PSP for each practical they attempt. Over time they will build up a personal history that can be used to improve the quality of their own work. In parallel with this, the software tools will collate a valuable database of class-wide statistics that will be immediately available to teaching staff.
The introduction of the lowest level of the PSP into Computer Science 1 was relatively straight forward. For each program the students write they are required to record the amount of time spent in the various activities associated with the assignment (design, coding, debugging, etc). Each defect found in the code or the design is also recorded, along with the length of time required to rectify the defect. This illustrates to students that time estimation is difficult, and that they are poor at it. It also points out to them the kinds of errors they commonly make and where they occur. Students keep these records over the course of one semester and write an essay on their findings. These essays, and the performance of the class in completing assignments, support the view that the PSP, even in this rudimentary form, is of significant benefit to the students.
Programming Techniques is a level-3 course undertaken immediately
be-fore the group-based project in Software Engineering and Project. Only a low level of the PSP was taught due to time constraints, but on completion of the group-based project, students confirmed that the use of the PSP had improved their productivity and their coding skills. Their time estimation skills have im-proved; errors as little as 10-20% are not uncommon.
Students found it difficult to quantify the improvement they experienced as a result of the PSP, but lecturing staff were able to discern a significant im-provement in the quality of the work submitted. In addition, the time taken to complete the major assignment in Software Engineering and Project was sig-nificantly reduced over previous years, confirming that the productivity of the students and the quality of the work submitted had indeed improved as a con-sequence of the PSP.
The subject Introduction to Software Engineering, which is for full-time Postgraduate Diploma students only, prepares them to undertake the final year subject Software Engineering and Project. The Postgraduate Diploma students are introduced to the basic elements of the PSP and provided with the opportu-nity to apply the process to several assignments before undertaking the group-based project in Software Engineering and Project. The Postgraduate Diploma students who had undertaken PSP training were deliberately grouped together in the project so that their performance could be monitored. It was found that the PSP training improved their performance over previous Postgraduate Di-ploma students and that these students, some of whom had not programmed until six months previously, were able to produce a working solution which was safer and more reliable than several solutions produced by students with
significantly more experience. When interviewed, the Postgraduate Diploma students indicated that they felt that the basics of the PSP to which they had been exposed had provided them with a competitive edge.
4
The Future
Given the success of the PSP in the classes who have used it to date, all sub-jects in the software engineering thread will be modified so that more and more of the PSP is taught as the students progress through the stream. It is expected that the complete introduction of the PSP will take 3 years to complete. This includes the time required to identify appropriate portions of the PSP to teach in each subject, the development of practical assignments to facilitate use of the PSP, the development of the appropriate lecture material, and development of appropriate software tools. The PSP in its current form is inappropriate to use in the undergraduate curriculum. The PSP has been designed for use in a post-graduate course where students have already gained significant experience. Although the PSP taught in such an environment may need to break some bad habits; the undergraduate environment is quite different. As students are learn-ing to program, they have no idea of what forms good practice and what does not. Consequently, great care must be taken to motivate each component of the PSP appropriately. This may force us to allow students to make errors so that they can learn from their mistakes. The difficulty will be to rectify these errors before they become habit.
5
Conclusion
Preliminary usage of the PSP in subjects such as Computer Science 1,
Pro-gramming Techniques and a special subject for Postgraduate Diploma students
are very encouraging. The Postgraduate Diploma students completing the equivalent of a major in Computer Science in one year full-time of study dis-played a good grasp of software engineering issues and produced very credible results in the group-based subject Software Engineering and Project.
The introduction of the complete PSP within the undergraduate curricu-lum remains unlikely. However, it is expected that the current course offerings will be modified so that increasing amounts of the PSP will be introduced in successive subjects. This will result in minimal disruption to each individual course whilst exposing students to a significant part of the PSP. The authors are confident that the deficiencies in the students’ education identified in Section 1 will be addressed and the students’ education enhanced. In addition, it is ex-pected that the PSP will provide sufficient productivity gains in the students that the perception of an excessive workload will disappear, and that the stu-dents will be able to complete their work in a shorter period of time. The con-cerns of industry are also be addressed, therefore increasing graduates employ-ability.
References
[1] J. Bentley, Programming Pearls, Addison Wesley, 1989.
[2] D.C.C. Bover, K.J. Maciunas, and M.J. Oudshoorn, Ada: A First Course in Software En-gineering and Programming, Addison Wesley, 1992.
[4] W.S. Humphrey, Managing the Software Process, Addison Wesley, 1990. [5] W.S. Humphrey, A Discipline for Software Engineering, Addison Wesley, 1995.
[6] M.J. Oudshoorn and K.J. Maciunas, Experience with a Project-Based Approach to
Teaching Software Engineering, Proceedings of the Southeast Asian Regional Computer
Confederation 5th Annual Working Conference on Software Engineering Education, Dunedin, New Zealand, IEEE Computer Society Press, November 1994, pp. 220-225. [7] M.J. Oudshoorn, A.L. Brown and K.J. Maciunas, Engineering Realistic Software in a
University Environment, Third International Workshop on Software Engineering
Educa-tion, Berlin, March, 1996. In Softwaretechnik-Trends, Band 16, Heft 1, Februar 1996, pp 47-51.
[8] M.J. Oudshoorn, A.L. Brown and K.J. Maciunas, Simulating Real-Life Software
Engi-neering Situations in the Classroom, Software EngiEngi-neering: Education and Practice, IEEE
Computer Society Press, 1996.
[9] M.C. Paulk, B. Curts, M.B. Chrissie, E. Averill, J. Bamberger, T. Kasse, M. Konrad, J.†Perdue, C.V. Weber and J.V. Withey, Capability Maturity Model for Software, Report CMU/SEI-91-TR-24, Software Engineering Institute, Carnegie Melon University, Pitts-burgh, August 1991.
