Clever Geek Handbook

PSP0 process and modern programming tools and languages

The Personal Software Process (PSP) is designed to enable software developers to understand and improve their performance. The PSP uses scripts to guide the practitioner through the process. Each script defines a goal, entry criteria, steps to execute, and exit criteria. PSP0 is designed as a foundation to start a personal process.

One of the scripts used in PSP0 is Development Script, which is supposed to drive development. This script is used when there is a requirement guide, a project plan summary, time and error logs, and a defect type standard is set. The activities of this script are design, code, compilation and testing. The script exits when you have a thoroughly tested application and complete time and error logs.

In the Code phase, you review the requirements and do the design, log the requirements defects to the log, and do time tracking. At compile time, you compile, fix compile-time errors, and repeat until the program compiles and writes any defects and timing. Finally, in the testing phase, you check until all tests run without errors and all defects are fixed during recording and defects.

My problems are related to how to manage the code, compilation and testing steps when using modern programming languages ​​(especially interpreted languages ​​like Python, Perl and Ruby) and IDEs.

My questions:

  • There is no compile time in interpreted languages. However, there may be performance problems. Does Script execute, outside of unit (and other) tests, considered "compile" or "check" time? Should runtime errors be considered "compile" or "experiencing" errors when tracking defects?
  • If a test case encounters a syntax error, is it considered a code defect, compilation defect, or test defect? The test did find a bug, but this is a code problem.
  • If the IDE identifies a bug that would have prevented compilation before actually compiling, should it be identified? If so, should it be identified and tracked as a compilation error or a code error?

It looks like PSP, at least the basic PSP0 process, is meant to be used with a compiled language and small applications written using a text editor (not an IDE). In addition to my questions, I would appreciate advice and comments from anyone using or using the PSP.

+2


source to share


5 answers


After reading the answers from Mike Burton , Vinko Vrsalovic, and JRL and re-reading the relevant chapters in PSP: The Self-Improvement Process for Software Engineers, I came up with my own solutions to these problems. However, it's good that I found a section in the book that I initially missed when two pages stuck together.

  • There is no compile time in interpreted languages. However, there could be performance problems. Is the script being executed, out of unit (and others) considered "compile" or "check" time? Should runtime bugs be considered "compile" or "check" bugs when tracking defects?

According to the book, it says that "if you are using a development environment that does not compile, you should just skip the compilation step." However, he also says that if you have a build step, "you can record the build time and any build errors at compile time."

This means that for interpreted languages, you either remove the compile phase from the tracking compilation or replace your build scripts. Since PSP0 is usually used with small applications (similar to what you'd expect in a university lab), I would expect you to have no build process and just skip this step.

  • If a test case encounters a syntax error, is the code considered a defect, compilation defect, or test defect? The test actually found a bug, but this is a code issue.


I would write down errors where they are.

For example, if a test case has a defect, it will be a test defect. If the test passed and an error was found in the application under test, it would be a code or design defect, depending on where the problem originated.

  • Should the IDE identify an error that will prevent compilation before actually compilation, if defined? If so, what should be identified and tracked as a compilation error or a code error?

If the IDE identifies a syntax error, that is the same as actually detecting the error before executing. When used correctly, the IDE has several excuses for resolving defects that can affect execution (as in the case of application execution errors other than logic / implementation errors).

0


source


In general, since PSP is a personal improvement process, the answers to your current questions don't matter as long as you pick one answer and apply it consistently. This way you will be able to measure the time you take in each specific phase, which is after the PSP. If your team is sharing PSP, you must all agree on which scripts to use and how to answer your questions.

My answers to relevant questions (not that they are relevant):

  • There is no compile time in interpreted languages. However, there could be performance problems. Is the script being executed, out of unit (and others) considered "compile" or "check" time? Should runtime bugs be considered "compile" or "check" bugs when tracking defects?

For me, testing time is the time when the actual tests are executed and not something else. In this case, both errors and runtime, which I would add as "compilation" time, are the time that is used to generate and run the code.



  • If a test case encounters a syntax error, is the code considered a defect, compilation defect, or test defect? The test actually found a bug, but this is a code issue.

Syntax errors are code defects.

  • Should the IDE identify a bug that would have prevented compilation before actually compilation, if defined? If so, what should be identified and tracked as a compilation error or a code error?

If the IDE is part of your toolchain, then it sees errors in the same way that you spot errors, and therefore code errors. If you don't use the IDE regularly, I would count them as compilation errors.

+1


source


I have been using PSP for years. As others have said, this is a personal process and you will need to develop a PSP0 to improve the development process. However, our team (all trained by PSPs) have tackled these challenges on several fronts. Let me give you an idea of ​​the components involved and then I'll tell you how we did it.

We had a PowerBuilder "level"; The PowerBuilder IDE prevents you from even saving your code until it compiles and links correctly. Part of the system used JSP, although the amount of Java was insignificant and boilerplate, so in practice we didn't account for it at all. Most of the system was in JS / JavaScript; this was before the great Ajax libraries came along and provided much of the work. The other bulk was Oracle Pl / Sql; it has a slightly more traditional compilation phase.

When working in PowerBuilder, the compilation (and linking) phase starts when the developer has saved the object. If the save was successful, we wrote down the compile time of 0. Otherwise, we recorded the time it took to fix the errors (errors) that caused the compile time defect. Most often these were defects introduced into the coding, removed during the compilation phase.

This forced compile / link component in the PowerBuilder IDE forced us to move the post-compile code review phase. Initially this gave us some concern because we were not sure how / if such a change would affect the meaning of the data. In practice, this has become a problem. In fact, many of us also carried over our Oracle PL / Sql code reviews after the compilation phase because we found that when we looked at the code, we often masked some of the syntax errors that the compiler would report.

There is nothing wrong with a compile time of 0, more than anything wrong with a test time of 0 (which means that your unit test passed without detecting errors and ran significantly faster than your unit). If these times are zero, then you are not removing any defects in these phases and you will not run into the div / 0 problem. You can also write down a nominal minimum of 1 minute if it makes you more comfortable or if your measures require a non-zero value.

Your second question is independent of development environment. When you encounter a defect, you record which phase you introduced it in (usually design or code) and the phase you removed (usually design / code review, compilation or test). This gives you a measure called "shoulder" that indicates the relative effectiveness of defect elimination in a particular phase (and supports the "general knowledge" that removing defects earlier is more effective than removing them later in the process). The phase in which a defect was introduced is its type, that is, a design or coding defect. The phase in which the defect is removed does not affect its type.

Likewise, with JS / JavaScript, compilation time is effectively immeasurable. We didn’t write once for the compilation phase, but again, we didn’t remove any defects in this phase. Most of the JS / JavaScript defects were introduced into design / coding and removed in project overview, code review, or testing.

+1


source


It sounds mostly like your formal process does not match your practice process. Go back, reevaluate what you are doing, and whether you need to take a different formal approach (if you actually need a formal approach to start).

0


source


  • There is no compile time in interpreted languages. However, there could be performance problems. Is the script being executed, out of unit (and others) considered "compile" or "check" time? Should runtime bugs be considered "compile" or "check" bugs when tracking defects?

Bugs should be classified based on when they were created, not when you found them.

  • If a test case encounters a syntax error, is the code considered a defect, compilation defect, or test defect? The test actually found a bug, but this is a code issue.

Same as above. Always go back to the earliest point in time. If a syntax error was introduced during encoding, then it corresponds to the encoding phase, if it was introduced during the error correction, and then in the defect phase.

  • Should the IDE identify a bug that would have prevented compilation before actually compilation, if defined? If so, what should be identified and tracked as a compilation error or a code error?

I believe that this should not be identified. It's just time spent writing code.

As a side note, I used the Dashboard Process tool to track PSP data and found it quite enjoyable. It's free and Java based, so it should work anywhere. You can get it here: http://processdash.sourceforge.net/

0


source






More articles:


All Articles