35 Personal Software Process

R. Baskaran

 

PERSONAL SOFTWARE PROCESS

 

Personal software process is a software development process by the developers to help themselves improve their performance and efficiency by following a personal disciplined framework that facilitates to plan, design, manage and measure their work.

 

LEARNING OBJECTIVES 

 

• To consistently improve the performance, engineers must use well-defined and measured processes.

• To produce quality products, engineers must feel personally responsible for the quality.

• It costs less to find and fix defects earlier in a process than later.

• The right way is always the fastest and cheapest way to do a job.

 

Better Programmer 

 

Better programmer can be achieved by,

  • More training
    • Know how to use tools.
    • Have seen some problems before.
    • Know how things fit together.
  • Familiar with language
    • Object, semaphore, recursion, etc..
  • Better process

 

Examples of Better Processes· 

  • Incremental coding
    • Code a little, test a little
    • Compare to writing entire program and testing
  • Error prevention versus debugging
    • Cheaper and easier to prevent than to find bugs

 

Point of Processes 

 

The point of processes is to learn from mistakes so that we never make the same mistake twice. It incorporates best practices as something works better than another.  A process executes routine standard tasks, when once the task is done it right once and then it is reused. Another major point of having processes is predictability.

 

PERSONAL SOFTWARE PROCESS 

 

Personal software process is a software development process by the developers to help themselves improve their performance and efficiency by following a personal disciplined framework that facilitates to plan, design, manage and measures their work. PSP helps you to manage your work & assess/build your talents/skills. It helps to plan better. And track your performance precisely. It measures the quality of your software products. It provides a framework for determining why you make errors and how you find them, to determine the quality of your reviews and the types of errors you make.

 

REASONS FOR A PROJECT FAILURE 

 

Large and small software projects fail for four reasons.

  • Project commitments are often unrealistic. The larger the project, the less influence we have. If we don’t have anything to say, nobody will listen and hence project fails when the project commitments are unrealistic.
  • Larger projects are harder to control. Today, few developers have personal plans, without a plan, you cannot know job status. If you don’t know where you are, management can’t understand job status. If management doesn’t understand job status, they can’t manage projects.
  • Quality problems get worse with project size. In software systems, if any part has quality problems, the system will have quality problems. If the developers do not manage quality, their teams cannot manage quality. When unmanaged, quality will always be poor.
  • To be effective, teams need leadership and coaching. Leaders build team motivation and commitment. Coaching develops team cohesion. Cohesive, motivated, and committed teams do the best work.

 

The Need for Changes 

 

Many lives and businesses now depend on software. We now need larger, more complex, and safer software systems on predictable schedules. Without different software practices, this will not happen. The Team Software Process (TSP) addresses this need. The PSP provides the knowledge and skill that developers need to work on TSP teams.

 

PERSONAL SOFTWARE PROCESS (PSP) 

 

Personal software process provides application of CMM principles to individuals. It was developed by Watts Humphrey of the Software Engineering Institute (SEI) in the early 1990s with extensive supporting materials such as books, courses, forms, exercises. It is validated by data from numerous projects such as:

 

◦ 58% reduction in defects/KLOC (development)

◦ 72% reduction in defects/KLOC (testing)

◦ 21% improvement in productivity

 

Personal software process is complemented by Team Software Process (TSP) which comprises of strict waterfall plus process monitoring and improvement.

 

The PSP is a personal process for developing software or for doing any other defined activity. The PSP includes defined steps, forms and standards. It provides a measurement and analysis framework for characterizing and managing your personal work. It is also a defined procedure that helps you to improve your personal performance.

 

PSP and CMM 

 

CMM is top-down – management oriented and PSP is bottom-up – engineer oriented.

 

Overview of PSP 

 

PSP is a disciplined personal framework for developing software and comprises of metrics, forms, and scripts. It produces low-defect products on schedule and within planned costs and manages quality, analyzes results and improves process.

 

The overall approach involves experienced programmers to inject one defect per 7-10 lines of code. People tend to make the same mistakes repeatedly. To improve the organization’s performance; record data on defects, review data, make process changes to eliminate causes and spend more up-front time (design and detection activities).

 

PSP Process Flow 

 

The PSP process flow involves acquiring the scripts which helps in planning the project and building the project with respect to the lines of code. The project is implemented and tested for shortcomings. The key feature in the process flow is to keep track of all the activities done by keeping a log of everything. The project summary report is generated which depicts all the data of the project and process executed.

 

Management Support

 

The initial TSP objective is to convince management to let your team be self-directed. Self- directed teams do the best work. A self-directed team

  • sets its own goals
  • establishes its own roles
  • decides on its own development strategy
  • defines its own processes
  • develops its own plans
  • measures, manages, and controls its own work

 

Web Links

  • www.sei.cmu.edu/tsp/
  • resources.sei.cmu.edu/library/asset-view.cfm?assetid=5287
  • cs.mty.itesm.mx/profesores/pverdines/TCS/p3/PSP-TSP.pdf

 

Supporting & Reference Materials

  • Roger S. Pressman, “Software Engineering: A Practitioner’s Approach”, Fifth Edition, McGraw Hill, 2001.
  • Pankaj Jalote, “An Integrated Approach to Software Engineering”, Second Edition, Narosa Publications, 2005.
  • Ian Sommerville, “Software Engineering”, Sixth Edition, Addison Wesley, 2000.
  • Watt.S.Humpherey, “Introduction to the Personal Software Process”, Pearson Education India, First Edition, 2002.