PSP BoK

今回のPSP試験対策でPSP BoKと言うのを読みました。
http://www.sei.cmu.edu/reports/09sr018.pdf

下記「個人的」に良いと思った所を上げておきます。ご参考まで。
#試験に出やすい所と言う訳ではないです。


1.1.4 Process documentation
The process documentation should not contain tutorial or other explanatory material typically needed by unskilled or uninformed individuals; it should provide only the necessary information that experienced practitioners require to enact the process steps.


2.2.5 Using data for planning purposes
however, any data (regardless of quality) are better than no data at all.

2.5.2 Scope for process improvement
The people who should perform the improvement work are the people who use the process: team members, teams, or even entire organizations.
People who are not currently using the process are typically incapable of defining usable and helpful improvements for those who are.
Large process improvement breakthroughs are rare, but small changes can be made almost every time a process is used.

3.3.8 Use historical data to make estimates
When making size estimates, find a way to use "whatever" historical data are available.

4.1.1 Plan the work
When individuals are involved in developing the plan, they are most likely to be committed to that plan.

When it is difficult to make an accurate plan, start with a preliminary plan and replan often.

4.6.2 When to adjust a plan
When work methods or processes are revised, the entire plan should be re-examined.

5.1.1 Personal responsibility
To produce quality products, individuals must feel personally responsible for the quality of their products.

5.6.2 Reviewing before or after compiling
Many development environments use automatic code analyzers and/or compilers that are quite helpful; their use is not discouraged.

5.6.3 Review objectives
Unless the individual is committed to producing high-quality products, the review process is likely to be ineffective.

6.1.1 Definition of software design
A software design transforms an ill-defined requirement into an implementable product specification.

6.1.4 The “requirements uncertainty principle”
The requirements for a software system are often not completely known until after the completed product is put to use.
The design process must provide a stable basis for this ongoing evolution.

6.2.1 The need for design strategies
Design is a complex intellectual process that cannot be automated, reduced to a routine procedure, or precisely controlled or predicted;

6.2.2 Nature of the design process
Design is a learning process that commonly requires moving between design levels and from one part of the system to another.

6.4.5 Design documentation practice
A useful practice when implementing a design is to start with the full program’s design and, as each design section is implemented, encapsulate that design segment in a comment immediately before the implementation.

7.1.2 How to define a new or customized process
Defining a new or customized personal process follows the same principles as those for software development:

7.3.1 Use effective methods for producing good work
Good practices are straightforward, but few people consistently use them.

7.3.2 Use data to discover strengths and weaknesses
Focus on making small improvements regularly, and major changes will take care of themselves.

7.3.3 Practice
The key to improving the quality of work products is to practice skills on the job to the maximum extent possible.

7.3.4 Learn from others, and pass it on

7.3.5 Find and learn new methods
Watch for innovations that are pertinent to personal needs.
Allocate time for skill building whenever possible.
Keeping up to date makes employees more attractive to their current employer (and to future employers) as a desirable and competent professional.