36 Personal Software Process II

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.

 

MANAGEMENT SUPPORT 

 

Self-directed teams are a bargain. Management will agree to manage your own work as long as they believe that you are doing a superior job. To convince them of this, you must maintain precise and accurate plans, measure and track your work and regularly show management that you are doing superior work. The PSP shows you how to do this.

 

PRINCIPLE OF PSP 

  • 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 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.

 

PSP Deliverables

 

A stable, mature PSP allows you to estimate and plan your work. It allows you to meet your commitments and resist unreasonable commitment pressures. It makes you understand your current performance and be better equipped to improve your capability. The PSP provides a proven basis for developing and using an industrial-strength personal process. It provides a discipline that shows you how to improve your personal process and the data to continually improve the productivity, quality, and predictability of your work.

 

Learning the PSP 

 

The PSP is introduced in six upward-compatible steps. You write one or more module-sized programs at each step. The data on your work is gathered and analyzed and the results are used to improve your personal performance.

 

PSP0: You establish a measured performance baseline. PSP1: You make size, resource, and schedule plans. PSP2: You practice defect and yield management.

 

PHASES OF PSP 

Overall PSP Strategy

 

The overall PSP Strategy includes:

  • Gather data
  • Estimate and plan
  • Manage defects
  • Manage yield
  • Control cost of quality

 

PSP Design Methods 

 

PSP does not prescribe a design method. Instead, it emphasized design completion and so it recommends making sure of the following:

 

Example schema 

 

◦  External static – Function interfaces: signatures, inheritance

◦  External dynamic – Operational scenarios, call/return

◦  Internal static – Attributes, constraints

◦  Internal dynamic – State machines, response time, interrupts

 

PSP Results

 

PSP achieves estimation improvement as reduced variance leads to better scheduling and staffing. It reduces compilation and test defects which is correlated with reduced customer- detected failures. It achieves mild productivity improvement.

 

PSP Benefits 

  • Increases personal commitment by investing each engineer with process responsibility.
  • Assists engineers in making accurate plans.
  • Provides steps engineers can take to improve personal and project quality.
  • Sets benchmarks to measure personal process improvements.
  • Demonstrates the impact of process changes on an engineer’s performance.

 

TEAM SOFTWARE PROCESS 

 

Humphrey developed an intermediate between PSP and CMM which included teams of two to twenty members and multi-teams of up to 150 members. It provides a tradition of statistical process control that is iterative (four to five month cycles) and comprises of scripts and forms.

 

Team Description 

 

A team consists of at least two people and the members work towards a common goal. Each person has a specific assigned role and the completion of the mission requires some form of dependency among the group members.

 

Effective Teams 

 

An effective team comprises of skilled members. The team’s goal is important and should be defined, visible, and realistic. The team’s resources are adequate for the job. The members should be motivated and committed to meeting the team’s goal. The members cooperate and support each other and are disciplined in their work.

 

Team Building 

 

The team members establish common goals and defined roles and develop an agreed-upon strategy. The team members define a common process for their work. All team members participate in producing the plan, and each member knows his or her personal role in that plan.

 

The team negotiates the plan with management and the management reviews and accepts the negotiated plan. The team members do the job in the way that they have planned to do it. The team members communicate freely and often form a cohesive group of members who cooperate and are all committed to meeting the goal. The engineers know their status, get feedback on their work, and have leadership that sustains their motivation.

 

TSP Launch 

 

TSP Strategy

 

TSP Strategy aims at creating a conceptual design for the product. It decides what will be produced in each cycle. TSP makes initial size, effort estimates and establishes a configuration management plan.

 

Selecting Roles 

 

The roles that are involved in TSP include;

  • Team Leader
  • Development Manager
  • Planning Manager
  • Quality/Process Manager
  • Support Manager
  • Customer interface manager
  • Design manager
  • Test manager
  • Safety manager
  • Security manager
  • Performance manager

 

Team Leader Responsibilities 

 

Team leader responsibilities include the following;

 

•  Motivating team members

•  Handling customer issues

•  Interaction with management

•  Day-to-day direction of the work

•  Protecting team resources

•  Resolving team issues

•  Conducting team meetings

•  Reporting on the work status

 

TSP Quality Guidelines 

  • Percent (of modules) Defect Free (PDF) at entrance to
    • Compile > 10%
    • Unit Test > 50%
    • Integration Test > 70%
    • System Test > 90%
  • Defects/KLOC: 
    • Total defects injected 75 – 150; If not PSP trained, use 100 to 200.
    • Compile < 10
    • Unit Test < 5
    • Integration Test < 0.5
    • System Test < 0.2
  • Defect Ratios 
    • Detailed design review defects /unit test defects > 2.0
    • Code review defects/compile defects > 2.0

 

Development Time Ratios 

  • Requirements inspection/requirements time > 0.25 Elicitation in requirements time
  • High-level design inspection/high-level design time > 0.5 Design work only, not studies
  • Detailed design/coding time > 1.00
  • Detailed design review/detailed design time > 0.5
  • Code review/code time > 0.5

 

Review and Inspection Rates 

  • Requirements pages/hour < 2 Single-spaced text pages.
  • High-level design pages/hour < 5 Formatted design logic.
  • Detailed design text lines/hour < 100 Pseudocode ~ equal to 3 LOC.
  • Code LOC/hour < 200 Logical LOC.

 

Produce the Quality Plan 

 

The quality plan estimates defect injection rates for each phase and estimates yield for each phase. It generate a trial quality plan which compares the quality plan with team goals. It examines and produces quality at each phase of the project. The time is modified and planned for defect removal if quality goals are not satisfied. Quality plan continues to generate trial plans until quality goals are satisfied.

 

Component Quality Profile 

 

The PSP/TSP criteria for a quality process are that

 

◦ Detailed design (DLD) time >= coding time.

◦ Detailed design review time >= 50% of DLD time.

◦ Code review time >= 50% of coding time.

◦ Compile defects <= 10 per KLOC.

◦ Unit test defects <= 5 per KLO

◦ Many defect-free components do not meet these

◦ All components that have met these criteria have been defect

 

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.