This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.
I the undersigned declare that the project material, which I now submit, is my own work. Any assistance received by way of borrowing from the work of others has been cited and acknowledged within the work. I make this declaration in the knowledge that a breach of the rules pertaining to project submission may carry serious consequences.
A course dedicated to software process must go further than a description of key practices, assessment approaches, the various life cycles and the many methodologies associated with software development. Successfully teaching software process and software process improvement means enabling students to understand the concepts behind the software processes, to increase their skills as team members and to contribute to the improvement of their own software process. There are many methods that can be used to teach software process and software process improvement, including using a process (UPEDU) to teach about the software development process, using case studies from real world examples and teaching students their own personal software process which they can use throughout their development careers.
The software development industry is very young compared to the majority of other industries . Where industries such as manufacturing have had time to develop impressive processes, standards and methodology the software industry is only beginning to evolve. This document will discuss a few of the many conventional and un-conventional ways in which computing students are taught about software process and software process improvement, including my own opinions on what way computing students should be taught software processes and software process improvement. I will be looking at and discussing Unified Process for EDUcation (UPEDU), a process for teaching software processes and other teaching methods, such as Problems and Programmers (PnP), a competitive physical card game that simulates the software engineering process, from requirements specification to product delivery. I will also discuss Personal Software Process (PSP) and provide a conclusion taken from the document and my conclusion on how computing students should be taught software processes and software process improvement. There are very many ways in which to teach students but it must be kept in mind that every method has its own advantages and disadvantages and for the optimal teaching method a balance must be struck depending on the audience.
I will discuss the advantages and disadvantages of each method and my own opinions from my experience as a student. Each student learns differently, where one student may excel with one particular teaching method another may fall behind. This must be kept in mind when choosing between teaching methods. Unfortunately the best approach is regularly the one that compliments the majority, which more often than not means some students lose motivation and fall behind. Successfully teaching software process and software process improvement means enabling students to understand the concepts behind the software processes, to increase their skills as team members and to contribute to the improvement of their own software process.
Robert M. Gagné, an educational psychologist, thought that "the cause of [students] failure in learning was the gaps in their knowledge of the sub-components of the tasks"  and in the oxford dictionary, a process is defined as "a series of actions or steps taken in order to achieve a particular end". It can then be said that if a process is a set of tasks or actions and a student's failure in learning is their lack of knowledge of the tasks, that knowing the process is integral to a students learning and success. This in my opinion could not be truer of the software industry. There are very few arguments against the adoption of software development processes, the majority of which state their misuse and subsequent failure because of this. These I feel lend to the argument that software process and software process improvement need to be taught in the beginning, to those who will shape the industry, the students.
2. Teaching Methods
Successful teaching of software processes and software process improvement involves motivating students to embrace the lifestyle of the software process and software process improvement. Many people in the software process field have said that it is similar to a religion. Those that learn it and embrace it typically want to pass on that knowledge to others and have them embrace it too. This I feel is key to successfully teaching any subject and not just software process or software process improvement. Motivating a student enough to learn a subject is not always enough though and in the field of software process and software process improvement it is a more of a life style than just the knowledge. Although there are many teaching methods, they can be irrelevant if students are not motivated. This lends to the argument that motivation must be a large factor in the teaching method used in teaching software process and software process improvement.
Teaching computing students about software processes and software process improvement gives them a model to understand and help manage project complexity  and eventually improve their own software process environment. Giving students a process which they can follow, speaking from a student's point-of-view is invaluable. A process can allow anyone, especially someone new to a subject, such as a student to begin complex projects, as it can provide at least a place to start. This section discusses different teaching methods, their benefits and pitfalls in teaching computing students about software process and software process improvement.
2.1. UPEDU - A Process for Teaching Software Process
Unified Process for EDUcation, or UPEDU, is a set of software engineering best practices that provide guidance for the educational environment. UPEDU is an academic customisation of IBM's Rational Unified Process (RUP), an iterative software development process . Many people criticised RUP for its 'weight' and complexity . Because of this, UPEDU tries to give students only the basics of the software development process, and assumes they will enhance this in their later careers. The objective is to introduce students to just the right number of software process activities to enable them to understand the role of software process in software development projects and to have them set aside activities which are more specific to a given task. The process model underlying UPEDU is based on the concept that a software process is the relationship between roles which perform operations or activities on entities called artefacts. UPEDU looks to provide a basic knowledge and understanding of a software process in a single academic semester and while assuming that students will complete their understanding and knowledge later on when they work on full software processes during their careers. The UPEDU course is divided up into thirteen weekly subjects, see table 1.
Software process is also linked to methodology. The methodology includes all aspects of software development, and is therefore more comprehensive than the software process. Although computing students could benefit a great deal from learning about methodology, UPEDU focuses more on the process and giving the student a basic knowledge of the entire software process. UPEDU is also web-enabled, this is the approach embodied in the Rational Unified Process (RUP). RUP is a Web-enabled software development process, which acts as online help by providing prescriptive guidelines and templates.
A short story about software process
Methods and tools
Software life cycle and software process
Analysis and design workflow
Software project management workflow
Configuration and change management workflow
Software process assessment
Software process measurement
Software process metamodel
Table 1 List of UPEDU subjects
Each separate subject has its own cognitive objective. For example the short story's objective is to show that the basic process of developing software is independent of the size of the organization . Hopefully this will impart to the students that the software process is more than a list of activities. In my opinion the best way to learn is the practical approach. The UPEDU process I feel favours this tactic, having the students perform an entire software process in groups. The case study provided by Pierre N. Robillard, Philippe Kruchten and Patrick d'Astous (2000), where thirty graduating students were taught using the UPEDU process, came to the conclusion with an outstanding rating. The students were given a product and in teams of six were taught while they performed an entire software process, designs were in UML and the end product was a java application which was accomplished in two iterations. This case study can also be supported by another similar case study where students applied software processes to their projects . Having the knowledge of what their learning objective was shown to improve student's learning and motivation. Each case study observed more student involvement in their respective courses, the majority of students registered higher interest in the course and therefore had greater motivation to work enough with the course to achieve good grades.
While I see this method as having many benefits I have one reservation, as with any college course it can be prone to student absenteeism, which could have consequences for the course or at least other team members if a single student were to not attend lectures. While this is a downfall it is also a very important part of software processes. At its base a software process is there to enhance the concept of the "team", I always look at a good software process as being greater than the sum of its parts, which is where this process could be a valuable lesson for students. Software processes should support the fact of availability issues by keeping knowledge within the entire team instead of the individual.
2.2 Case Studies
This approach is common among software process and software process improvement courses and is gaining ground in other areas . It's a method that can be very effective . Software process and software process improvement is comprised of both technical and managerial issues. Among the technical, we list design, testing, inspection, and configuration management. On the other hand, the quality and improvement models, like Capability Maturity Model, ISO 9000, etc. derive from managerial and organisational theories . Case studies can be used to show companies losing money or failing altogether due to having little or no software development process. As with 4th year students in DCU many students have worked in a software development company, and can therefore find it difficult to not relate it to their own experience. This can mean that students are not motivated about the software process as all they can relate to is the companies they've worked for ,which more likely then not have some sort of formal process in place whether they have had interactions with it or not. Case studies can allow students to get a deeper understanding of the software process and how it affects entire companies. For many software processes and their improvement can be a less interesting subject than others, involving much theory and tedious standards. Case studies can be capable of providing an insight into how these subjects work in practice and their overall consequences. Many of the case studies of teaching software process and software process improvement using case studies have noted an increase in student participation, and that students relate better to real world examples than general lectures on the theory.
It was also noted that the companies, students and case studies focused more on the processes than the quality that the processes produced. Therefore there was decreased student motivation, which is key to the teaching of software process and software process improvement. Teaching with the use of case studies can range from reading about companies successes and failures involving software processes and improvement to including actors and guest speakers from actual companies. Where this approach can be very effective it should be acknowledged that styles and modes of learning vary from student to student. While certain students work very well in this situation, others are more efficient in formal time-constrained settings or in a more hands-on approach. In my opinion I feel this method does not cover the vast majority of students where other methods would be more effective to a greater number.
2.3 PARTENAIRE - A Cooperative Learning Environment Based on Lotus Notes
Marie-Michéle Boulet from the University Of Laval, Quebec is very active in the area of distance learning for software management. Boulet added a co-operative learning-working environment based on lotus notes (named PARTENAIRE) to her Information Technology undergraduate course in the university . This method is included as an unconventional approach to teaching. Students were provided with thirteen documentaries, a study guide, a mandatory book, exercises, lotus notes environment and phone or electronic assistance. The course implemented Gagné's principals of learning including teaching attitudes as well as three areas in the cognitive domain. The main objective of this case study was to observe the relative effects of television distance learning versus traditional classroom learning. The result observed was that there was no decrease in the students' learning through the use of documentaries, lotus notes environment and other distance learning resources.
In DCU I have observed lecturers produce video lectures for students to follow and still provide the option of attending lecturers if they have questions, but otherwise have no reason to attend scheduled lectures. This in my opinion provides vast flexibility and does not prevent students from learning even if they decide not to attend lectures for various reasons. There is also the added capability of reviewing the lectures multiple times, especially when examinations loom. Where I can see many benefits to this approach, I feel it would not suit everybody, especially in a practical course such as software process and software process improvement.
2.4 Problems and Programmers (PnP)
Problems and programmers (PnP) is a competitive card game that simulates the software engineering process, from requirements specification to product delivery. Each student plays the role of a project manager, competing to be the first to complete the project satisfactorily. Each participant hires other students as programmers and decides on the order in which development tasks are performed. Both groups of students are constrained by the project budget and client demands for product quality. Players interact by playing problem cards against their opponent. The abstract nature of the project deliverables means that the software process is the focus during the game. The rules of the game are easy to understand and its physical nature allows for face-to-face interaction between students, as well as being playable in the classroom without the need for computers. A game typically takes 40-50 minutes to play. The variety within the game provides numerous scenarios to explore . While the game itself is useful, it is intended to supplement the usual approaches taken in a computing course, not replace them. Often, too little attention is given to how a complementary academic tool of this kind can be smoothly integrated into a software engineering course.
While In my opinion the problems and programmers game has many benefits as a supplementary learning tool to help reinforce the concepts of a software process or software process improvement course in an entertaining way, the game is relatively simple. The problems and programmers game can provide students with valuable lessons about a wide range of concepts and possible problems associated with the software process. However the simplicity of the game can hide the common complexities encountered in student software projects. This approach would in my opinion provide many benefits and insights into the software development process, although this would have to be used in conjunction with a broader teaching method such as the use of case studies or UPEDU.
3. PSP - Personal Software Process
The Personal Software Process (PSP) provides engineers with a disciplined personal framework for doing software work . The objective of the PSP is that to produce quality software systems, every developer who works on the system must do quality work. The PSP was born out of Watts Humphrey's decision to apply CMM principles to writing small programs. The design of the personal software process was based on Humphrey's planning and quality principles, see table 2. The full PSP curriculum leads practitioners through a sequence of seven personal processes. The first and simplest PSP process, PSP0, requires students track their time and defect data using a Time Recording Log and Defect Recording Log, then fill out a comprehensive Project Summary Report. Later processes become more complex, introducing scheduling, size and time estimation, and quality management practices such as defect density prediction and cost estimation. The PSP could be taught to all computing students before having any real world experience as it does not depend on any experience within a real software process. Having learnt a personal software process it would greatly benefit all courses in all years and continue later into a student's career. However it is my opinion that the student must appreciate the benefits of the software process and the consequences of its improvement before being able to effectively implement a process such as the personal software process therefore students early on in college would probably not be suitable to undertake such a large activity effectively.
Every engineer is different; to be most effective, engineers must plan their work and they must base their plans on their own personal data.
To consistently improve their performance, engineers must personally use well-defined and measured processes.
To produce quality products, engineers must feel personally responsible for the quality of their products. Superior products are not produced by mistake; engineers must strive to do quality work.
It costs less to find and fix defects earlier in a process than later.
It is more efficient to prevent defects than to find and fix them.
The right way is always the fastest and cheapest way to do a job.
Table 2 PSP planning & quality principles
The personal software process would be very beneficial to all computing students as this would enhance their project planning and reduce complexity therefore allowing students to efficiently produce quality projects and learn the importance of software process and software process improvement. As many students have multiple deadlines and objectives having the capability to plan and measure personal performance would not only help them in their studies it would also be beneficial in their later careers, allowing them to consistently produce quality products from the beginning of a job. The number of forms to be filled out during the personal software process can seem overwhelming to many students. The personal software process starts with a requirements statement; there is a planning script that guides the work and a planning summary for recording planning data. While the students are following their individual scripts to do their work, they record their time and defect data in logs. At the end of their job they summarise the time and defect data from the logs, measure the program size, and enter this data in the plan summary form. This allows for students to fully understand their process and improve on it in the future. From experience students can never receive too much feedback. Feedback I feel is the most effective way of learning and improving. Therefore the PSP would allow students to track their own progress and essentially give themselves feedback. As the PSP is abstract from the project implementation, meaning it can be applied across multiple subjects, benefiting students greatly. The PSP is a discipline which students would learn to work by, this has been proven effective in many case studies . One downfall of the personal software process would be incorporating PSP into an existing course, where the same programming topics still need to be covered in approximately the same depth, and any time spent in class on personal software process would take away from time to be spent on programming topics.
While PSP planning scripts describe what to do, they are more like checklists than tutorials. They do not include the instructional materials that would be needed by students who had not been taught how to use them. The purpose of the script is to guide students in consistently using a process that they understand. Therefore students would need to be taught early on and perhaps guided through an entire project using a personal software process. This would be very beneficial to students, giving them the power and knowledge to understand their individual method for completing projects and allow them to improve on a continual basis. Where teaching the personal software process has many benefits to students it would be too large for them to actively use throughout their courses. The PSP has many visible educational benefits although there can be certain limitations. Since the PSP's introduction, several case studies (M. Ramsey, "Experiences Teaching the Personal Software Process in Academia and Industry," Proc. 1996 Software Eng. Process Group Conference, 1996; Barry Shostak, "Adapting the Personal Software Process to Industry," Software Process Newsletter, No. 5, Winter 1996; Pat Ferguson et al., "Introducing the Personal Software Process: Three Industry Cases," Computer, May 1997, pp. 24-31) have reported positive experiences. While noting the many visible academic benefits, each study defined a few limitations. These limitations included the amount of paperwork as the highest drawback to the personal software process. While keeping these limitations in mind, it is still clear that the benefits of teaching the personal software process to students outweigh the drawbacks.
There are many different ways to teach students subjects such as software process and software process improvement and they all depend on the student. In my opinion the best way in which software processes and improvement should be taught is a practical approach, one in which the student performs an entire software process or perhaps improves on one. By actively partaking in the software process the importance will become apparent to the student, as with UPEDU or PSP the student would undertake a project from start to finish using a documented formal process. Later on in a career a student may only be present in a small portion of a larger software process and having completed an entire process from start to finish will give them a higher view an allow the student to understand where they fit into the bigger picture. Having worked in an entire process I feel it would give students the tools to efficiently produce quality software repeatedly.