Personal Software Process

2012-10-30

book-review

The Personal Process Strategy
A personal software process is something that you use to guide your work.
The Baseline Personal Process
A defined process can help you understand your performance as a software developer and to see where and how to improve.
With PSP0, you measure the time spent in each development phase and the defects you inject, find, and fix.
Use a support tool to record time and defect data.
Measuring Software Size
Reason in measuring software size: planning use. The size measure should correlate to development effort, be precise, and be automatically countable.
Typical size measures are database elements, source program lines of code, pages of design or text, and function points.
Counting logical lines by using a coding standard and a physical counter.
For each program version, you need to know the number of added and deleted elements or lines.
A practical way is to use a line counter program to compare the current version and its predecessor.
Well-defined and consistently used size measures can provide the data needed to make accurate size and development estimates. Size data are also useful for comparing defect rates among programs.
Planning
Planning is the first step in the PSP for three reasons:
Without good plans you cannot effectively manage even modestly sized software projects.
planning is a skill you can learn and improve with practice. If you don’t learn how to make good plans now, it’s almost impossible to pick up on the job.
good planning skills will help you do better software work.
In software engineering, as in other fields, the role of the developer is to devise economical and timely solutions to the employer’s needs. Making plans that accurately represent what you will do.
Software Estimating
Estimates are generally required before you can being development.
At early stage, you may generally understand the requirements but know little else about the project.
A proxy is needed to relate product size to the required product functions.
The criteria for a good proxy are that its size should be closely related to the effort needed to develop the product and that it can be automatically counted.
It should be easy to visualize at the beginning of the job and be sensitive to language, style, and design differences that might affect the development effort.
In using proxy, divide data into ranges that correspond to the sizes of the proxy items in database, label them VL, L, M, S, VS.
The PROBE Estimating Method
The quality of plans will depend on the quality of estimates. The accuracy, in turn, will depend on the quality of the data and the soundness of the estimating method you use.
The PROBE method provides a statistically sound way to make estimates.
When using PROBE, you gather estimated and actual size and time data for each project. Then you divide the data into categories and size ranges. The estimating process starts with a conceptual design followed by an estimate of the PROBE method shows you how to estimate program size and development time.
Two sources of error: estimating accuracy will fluctuate around some mean or average; the estimate will typically have some bias.
Software Planning
Once you have estimated the size and development time for a project, you can produce the project schedule.
With an estimate of the hours you will spend on project tasks each week, you can spread the estimated development time over the project schedule.
Weekly task hours are usually 50% of the working time.
You can calculate when each task will start and end, and also get dates for the key point milestones.
Earned value provides a way to measure and track job progress. It establishes a planned value for every week based on the task’s percentage of total project development time.
Earned value provides a common measure for the value of every task, regardless of the type of work involved.
Software Quality
To improve the quality of your software, focus on the process required to consistently produce quality products. Seek the most effective methods for finding defects and the most effective ways to prevent them.
The cost of finding and fixing defects escalate rapidly the longer the defects remain in the product.
The most cost-effective strategy is to ensure that all program elements are of the highest quality when first produced.
Defects are rarely the user’s top priority, but they are an essential focus on PSP. This is because defects are most economically and effectively handled at the individual level.
Software quality is an economics issue. You can always run another test or do another inspection.
PSP provides the data needed to calculate measures for yield, cost of quality, rates and ratios, and the process quality index (PQI).
The software process can be viewed as the combination of two competing processes: defect injection and defect removal.
Design and Code Reviews
The purpose of a review is to efficiently produce a high-quality program. The principal kinds of reviews are inspections, walkthroughs, and personal reviews.
Reviews should be done for the requirements, the design, the documentation, and all other product elements.
Design and code reviews are much more effective than testing for finding and fixing many defects.
Reviews find defects directly, while testing provide symptoms.
Reviews provide a greater return on your personal time than any other single thing you can do.
Read each program, study it, and understand it. Then fix the defects, the logic, the structure, and the clarity.
Learn to rewrite programs. When areas are not unclear of confusing, add comments, or better yet, do a complete rewrite.
To determine whether reviews are helping to achieve goals, measure them. Use a Pareto distribution to establish review priorities and to develop a review checklist. Re-examine the Pareto distribution periodically.
Software Design
Many of software development’s historic problems have stemmed from a misplaced expectation that development should start with firm and complete requirements. History demonstrates, however, that for a new software system, the requirement will not be completely known until after you have a working product, and possibly not even then.
The design phase of large-scale software systems typically start with a high-level system design effort that subdivides the product into components. And each components are separately developed and system is integrated.
A well-founded development strategy is built on the natural structure of the planned products.
Although there are many possible development strategies, they are all different forms of divide-and-conquer.
There are two aspects to software design: how to produce the design and how to represent that design once it is produced.
The PSP Design Templates
In PSP, designs are described with the aid of four templates:
The Operational Specification Template describes the program’s operational behavior via one or more scenarios.
The Functional Specification Template describes the functions performed by a program, a class, or a procedure.
The Logic Specification Template uses pseudo-code to precisely describe a program’s logic.
The State Specification Template describes the program’s state behavior.
You can use these templates to specify the internal and external behavior of both large systems and small systems, as well as the behavior of their parts.
The intent is for developers to produce designs in whatever methods work best for them and record these designs in the PSP templates.
Design Verification
The objective of design verification is to determine whether a design meets its requirements and is correct.
Methods: trace table, state-machine analysis, analytical verification.
Using these methods saves time because when your designs are complete, clear, and correct, the implementation will be faster and the finished product will have few design defects.
Although trace table is time-consuming, it is much faster and more effective than verifying all possible cases with testing.
Conditions for a correct state machine: all state transitions should be complete and orthogonal; the machine must be able to reach a program return state from every other state.
Verifying design correctness is simple in concept, but it takes time to build sufficient skill to do it quickly and effectively.
Process Extensions
Software process development is much like software development, in artifacts, disciplines, and methods.
Steps: define needs, establish goals, define quality criteria. Next, characterize the current and target processes and establish a development strategy. Finally, define and validate the initial process and establish means for its enhancement.
It’s practically impossible to produce a usable process the first time you try.
The perceived process is what you think you do; the actual process is what you actually do; the official process is what management thinks you do; and the target process is the process to which you are evolving.
Process development should be planned, measured, tracked, and improved.