1 / 20

The Software Process Strategy

The Software Process Strategy. The Software Process Strategy Part II. 2.1 The Baseline Process. The PSP0 process is shown in simplified form in fig.2.1.

solada
Download Presentation

The Software Process Strategy

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. The Software Process Strategy The Software Process StrategyPart II

  2. 2.1 The Baseline Process • The PSP0 process is shown in simplified form in fig.2.1. • The scripts guide you through the process steps, the logs help you record process data, and the plan summary provides a convenient way to record and report your results.

  3. Figure 2.1

  4. 2.3 The PSP Process Elements • The PSP0 process is shown in fig.2.2. • First, in the planning step, you produce a plan to do the work. Next, you do the software development. • At the end, in postmortem step, you compare your actual performance with your plan, record the process data, and produce a summary report. • While these planning and postmortem steps may not seem necessary when writing small programs, they are essential to building a disciplined personal process.

  5. Figure 2.2

  6. 2.3 The PSP Process Elements (cont.) • Large defined processes, for example, will have many elements or phases, each of which can also be viewed as defined processes. • At the lowest level, the process phases will be composed of steps that have no further defined substructure. • In the case of PSP0, the planning, development, and postmortem phase have process definitions but design, code, compile, and test are named as undefined steps. When it has no defined structure, I call it a step or a task.

  7. 2.4 The PSP0 Process • The PSP script guides you thought a process. The principal elements of this script are its purpose, the entry criteria, the phases(or steps) to be performed, and the exit criteria. • The PSP0 process script is shown in table2.1. It describes in words the simple process structure shown in fig.2.2.

  8. Table 2.1

  9. 2.4 The PSP0 Process (cont.) • The planning and postmortem phases are quite clear from the scripts in shown in table2.2 and 2.3, but the development phase in table2.4 has four steps: design, code,compile, and test. • Until these steps have explicit entry and exit criteria, there is no way to tell when each starts or ends. One common confusion, for example, concerns the distinction between code and compile. • Count the time spent correcting compile defects as compile time. Similarly, the time spent correcting and compiling test defects is counted as test time.

  10. Table 2.2

  11. Table 2.3

  12. Table 2.4

  13. 2.5 PSP0 Measures • The PSP0 has two measures: • The time spent per phase • The defects found per phase

  14. 2.5 PSP0 Measures (cont.) • The time spent per phase is a simple record of clock time • You spend in each part of the PSP process. You objective • is to determine where you spend the bulk of your time • and how that distribution change your process. • for the PSP you should record your time in minutes. • Recording defect data is a little trickier. You should record data • on every defect you find during compile and test. • A defect is counted every time you make a program change. • The change could be one character, or it could be multiple • statements. As long as the changes all pertain to the same compile or Test problem, they constitute one defect.

  15. 2.5 PSP0 Measures (cont.) • Some compilers generate multiple error messages for a • Single defect.If these were all connected to one problem,then • you would merely count it as one defect. You should also count • defects in your test procedures. • They give you a baseline against which to measure your • Performance, show where you spend your time, and indicate • Where you make and find the most defects. You can then • decide for yourself how the process changes affected the • Productivity and quality of your work.

  16. 2.6 Time Recording Log • Table 2.5 shows the PSP Time Recording Log, and Table 2.6 • contains the instructions for completing it. • If you consistently ignore the time such interruptions take, • you will not have an accurate idea of the time you spent on • various tasks. • Often, you will forget to record the start time or the stop time • of a phase or of an interruption. You should then make • your best estimate of the time involved. • Another problem you will likely have is deciding when a step • starts or ends.

  17. Table 2.5

  18. Table 2.6

  19. Table 2.7

  20. 2.6 Time Recording Log(cont.) • Compile is another example of the confusion about phase • boundaries. The time you should enter for compile is the time • You spend getting your program to compile completely the • first time. • As you fix the defects you find in test, however, these • changes must also be compiled. This time should be • entered as part of the test phase and not as part of • compile. • Compile ended with the first successful compile. • With some interpretative and fourth-generation systems, • of course, there is no compile time. In this case, you • would drop this phase and go directly from code to test.

More Related