We are discussing four project management and development practices in the following article: Process requirements, Document review, Defect removal process and Pair programming.
The importance of product quality criteria has been stressed. However, the qualities required in a product are captured by following the correct processes that create the product. This makes it necessary to specify the process requirements for each stage and activity.
Entry requirements state what must exist before the stage or activity can begin. For example, before design can begin, the requirements documentation must be agreed and signed off and any design techniques to be used must be specified. If design begins before requirements are agreed, this will lead to problems if the requirements are changed during design. The design may then have to be reworked at additional cost; worse still, the need to amend the design in line with changes in the requirements may be forgotten.
Implementation requirements define how the process should be done. For example, in design, implementation requirements may specify the use of techniques such as entity modelling or logical process modelling. Implementation requirements also specify the software tools that are to be used.Exit requirements indicate what should be in place for a successful sign-off of the activity. The exit requirements for design documentation are that it:
- is complete;
- has been reviewed;
- meets the standards agreed;
- covers all the requirements for this component;
- leaves no outstanding issues.
Defect removal process
Before a defect can be removed, it must be identified. This is relatively straightforward – though more costly – in the later stages of development, when test cases can be run though the system to see if they give the expected results (dynamic testing). In the earlier stages of a project, quality checking could involve the following:
- desk checking;
- document review;
- peer review;
- pair programming;
- static testing.
When specifying quality criteria that apply to, say, a software specification, the technique for checking if those criteria are met should be specified, along with the type of staff and tools needed.
Desk checking is the most basic of the review activities. When you produce something, you yourself should be the first person to check it. After all, you are the person who knows most about what you were trying to do. This may mean reading it through and checking for mistakes and ambiguities in a document, or working through the logic of software to identify slips with code. It will, hopefully, remove many trivial errors before the product is subjected to more vigorous scrutiny.
This too is desk checking, but by people other than the author to ensure that the document meets specified quality criteria, such as appropriateness and clarity. The readers may have particular concerns: a user could be concerned that a requirement satisfies the daily needs of their job; a coder might be concerned that it gives a clear indication of what the software must do. Products created in a project are not self-contained, and must be compatible with other products.
Concerns might include: is it complete, unambiguous, self-consistent and consistent with related documents? Is it clear? Are all technical terms properly used and understood? Does it conform to the agreed layout?
A walkthrough is a particular technique where a scenario is created of a real-world situation (called ‘user stories’ in Agile). How the new system will deal with the situation is worked through and discussed, step by step. The participants could be drawn from both technical and user groups, each of which may have a different view on the proposed transaction. This is particularly useful in assessing early proposals for interface designs. Please have in mind that this is not a traditional project management practice. Check out what is project management on Brighton’s website.
A peer review is a type of document review that is often carried out on a design document or actual code. The author’s co-workers (or peers) examine copies of the document and make comments about it. The issues considered include:
- Is the proposed design technically feasible?
- Is there an easier or better way to achieve the same objectives?
- Does the design conform to company standards for such processes?
- Can the design communicate with other parts of the system?
- Does the design cover all the requirements that should be included?
- Are there any ambiguities?
The peer reviewers of software often carry out a version of a walkthrough where they dry-run the code – that is, take some test input data and manipulate it on paper according to the instructions in the code.
Peer reviews can be done relatively informally within the project team. However, the time needed by the reviewers needs to be officially scheduled – after all, they have their own software on which to work as well.
An inspection is a formal review of a product. Its purpose is to review the product in order to identify defects in a planned, independent, controlled and documented manner. It is a process with the following structure:
- setting up the review meeting – including the time, place and who is to attend;
- distributing documentation – for example, the product and its description;
- annotation of the product by reviewers, if it is a document, and recording defects.
- discussion of potential defects identified by reviewers, which should confirm whether they are defects or not, but not seek to produce a solution;
- agreement of follow-up appropriate to each defect.
- follow-up actions and responsibilities;
- agreement of outcome and sign-off if appropriate.
- advising the project manager of the outcome;
- planning remedial work;
- signing off when complete.
There are four roles within this process
1. The moderator sets the agenda and controls the review process, ensures actions and required results are agreed and, once the process is complete, signs off the review.
2. The author provides the reviewers with relevant product documentation, answers questions about the product during the review and agrees actions to resolve defects.
3. Reviewers undertake the review, assessing the product against the quality criteria, identifying potential defects and ensuring that the nature of any defect is clearly understood by the author.
4. The scribe takes notes of the agreed actions, who is to carry them out and who is to check corrections. He or she confirms these details at the end of the meeting.
With peer reviews, inspections and walkthroughs, no attempt should be made during the meeting to solve the problems identified. Problems should be recorded. The author will then go away and seek to come up with solutions. The review can then be repeated if it is felt that the changes required were of sufficient significance. An alternative is for one person to be given responsibility for ensuring that the necessary alterations are made by the author.
The review techniques described above depend on copies of documents, including code, being printed and additional reviewing activities being scheduled. To avoid this, in Agile development environments, code developers sometimes work in pairs. The pair take turns to type in code at the workstation while the other advises and checks on what is being entered. This is rather like a real-time version of a peer review.
Some software tools carry out static testing by analysing the structure of the code. Among other analyses, such tools look at the branches and loops in a program and calculate a measure of complexity. The more complex a software component is, the more difficult it will be to maintain.
All the above processes take place during the activities on the left-hand side of the V model. The quality control processes on the right-hand side are dominated by dynamic testing.