Today, there are many software products in the world which are developed by

human. Although many quality software products have been produced, there are not

quality software products which are developed. In general, there are various factors

contributing to non-quality software products such as time, budget, and so on.

Nevertheless, the most reason of non-quality software is a lack of control quality in

the early stage of software development. Some software developers have believed

that software quality is the process which they will concern after code has been

generated - this is a significant myth. In fact, software quality control is a prevent

activity which start from beginning of developing software process until software

product is delivered to stakeholders. Some statistics illustrate that analysis and

design phases, early stage of software development, can lead to 50% – 60% of all

errors occurring in the developing software process. While some software

developers use several tools to address it, the others decide to use some techniques

instead of tools. In my point of view, the proper way to manage defects in the early

stage of developing process is techniques. In this essay will describe the advantages

of techniques which use to fix these errors.

These techniques relate to software quality management which can result in a

less bug software product than the other, which do not use. Quality concept is

controlling variation, and this is the heart of quality control from one project to

another project. Software developers try to minimize the divergence between the

predicted resource fundamentals to complete their project and the exact resources

used, such as staffs, equipment and time. Due to the fact that they desire to assure

their software are covered by testing program. In addition, software developers not

only deduct a number of errors, but also ensure that the variation in the great of

defects is controlled from one release to another project (Pressman 2005).

Pressman also states that quality of design covers requirements, specifications and

the design of the system, as well as, quality of collaboration is a topic that is

emphasized mainly on implementation. Thus, if the implementation is followed by

design and resulting of product meets its requirements, quality of collaboration is

high. However, the quality of design and collaboration are not enough that software

development have to be concerned. Glass states that the other thing is should be

considered by software development is

‘user satisfaction = compliant product + good quality +

delivery within budget and schedule’ (Pressman 2005, p.746).

He significant emphasizes that quality is important. However, if the stakeholder is

unsatisfied the software, the quality means nothing. Additionally, like Glass,

DeMarco strongly agrees with this view and contends that ‘A product’s quality is a

function of how much it changes the world for the better’ (Pressman 2005, p.746).

In many aspects of software quality, according to Pressman (2005), he

highlights the definition of software quality as

…1. Software requirements are the foundation from which quality is measured.

Lack of conformance to requirements is lack of quality.

2. Specified standards define a set of development criteria that guide the manner

in which software is engineered. If the criteria are not followed, lack of quality will

almost surely result.

3. A set of implicit requirements often goes unmentioned (e.g., the desire for ease
 of use and good maintainability). If software conforms to its explicit requirements

but fails to meet implicit requirements, software quality is suspect… (Pressman

2005, p.748).

Quality control may be equated to variation control, and the quality control

involves many activities, such as the series of inspections, reviews, as well as, tests

used, which assure the products meet its requirements. In terms of quality

assurance, it encompasses a set of auditing and reporting functions evaluating the

effectiveness and completeness of quality control works. The providing management

is informed crucial information that is the goal of quality assurance. As a

consequence, the product will meet its goals.

In the respect of cost, the cost of quality consists of all costs which are

occurred in the chasing of quality and in performing quality; relative activities.

According to McBride (2011), a quality problem can be defined as ‘the product will

not get enough financial return’ which can contribute to rework job if the product has

not a good quality. Thus, the stakeholders may be unsatisfied. He further argues that

it has been proven that the organization will be save their money by good quality;

more than the extra work required – rework. Therefore, it can be stated that ‘quality

is indeed free’ (McBride 2011).

The first technique which can control the defect that occurs in the early stage

of software development mentioned in this essay is software quality assurance. The

quality assurance was emerged at Bell Labs in 1916, and then it was extended

swiftly throughout the manufacturing world. During the 1970s, standards for software

quality assurance were introduced in military contract software development which

expands rapidly in developing software in the commercial world (Software

Engineering Standards 1994 cited in Pressman 2005). Schulmeyer and Mcmanus

note that software quality assurance can be defined as ‘planned and systematic

pattern of actions that are required to ensure high quality in software’ (Pressman

2005, p.749). According to Pressman (2005), there are many software quality

assurance responsibilities in software developing project, such as software

engineers, project managers, customers, salespeople, and the individual persons

who serve within a software quality assurance group. The software quality assurance

groups have commitment for quality assurance planning, uncovering defects, record

keeping, analysis, and reporting (Pressman 2005). This can contribute to software

products that have good quality or high quality through providing the proper technical

methods and reviews, standard measures, as well as, performing well-planned

software testing for software engineers to manage quality of software.

In addition, as Pressman (2005) argues, there are 6 activities that are

performed by the software quality assurance group; an software quality assurance

plan for a project will be prepared by software quality assurance group, the software

quality assurance group participates in ‘the development of the project’s software

process description’, and it verifies the compliance requirements which are approved

in the analysis and design phases through supervising software development

activities. It also audits software work product to verify the working of software

should be followed by the requirements. Moreover, it guarantees that deviations in

software work and work products are verified and addressed according to a

documented procedure, as well as, notes any non-compliance found and reports to

their manager management.

 Furthermore, these activities of software quality assurance group further

support analysis software metrics. As this essay mentioned above, the software

quality assurance group can contribute to solving early defects in the early stages of

software development by controlling developing software process, tracking, and

supports the software developing team so that complete a good or high quality

software product.

Turn to the other technical software quality management, which can deal with

the defects that are happened in the early stages of software development, software

reviews play as a filter using for the software process. The software engineering

activities can be purified by the software reviews method, if the software engineering

applies this reviews into each software development phase; analyslis, design, and

coding. Both Freedman and Weinberg argue that

…Technical work needs reviewing for the same reason that pencils need erasers:

To err is human. The second reason we need technical reviews is that although

people are good at catching some of their own errors, large classes of errors

escape the originator more easily than they escape anyone else… (Pressman

2005, p.751)

Various divergent types of reviews can be managed as part of software

development. One of the good informal places for meeting is coffee shop. There are

many discussion groups in this place because the group members who join the

discussion feel comfortable to review and brainstorming.

 Nevertheless, in this essay will focus on the formal technical review (FTR);

walkthrough or inspection. As Pressman (2005) states, the formal technical review is

the most effective filter from a quality assurance viewpoint, which is conducted by

software developing development, for uncovering defects; especially in the early

stages of software development, as well as, improving software quality. The formal

technical review has a major objective that is to find defects during the process so

that the stakeholder do not encounters the defects after the software is release in the

last version. One of the clearly advantages of the formal technical review is the early

uncovering of defects. As a result, these errors will not propagate to the next phase

of developing software process.

A number of recent researches (TRW, NEC and Mitre Corp) illustrate that

even though the design phase can lead to a large number of defects happen in the

early stages of software development; between 50% and 60%, the formal technical

review have been indicated to be up 75% effective in uncovering the design fault via

detecting and addressing a large percentage of these faults. Implementing Software

Inspection 1981 provides a defect amplification model to shows the generation and

detection of defects which are during the preliminary design, detail design and

coding stages of a software development process (Pressman 2005, p.752)

 Defect amplification model

According to Pressman (2005), the defect amplification model represents a software

stage. During the stage, the defects may be created. Although the formal technical

review may fail to uncover errors from next and previous steps; some errors are

passed through, the error are less than the other which do not use the formal

technical review.

Defect amplification model – no reviews

 Defect amplification model – reviews conducted

Both pictures indicate the comparison of the software development which uses and

do not uses the formal technical review via the defect amplification model. Referring

to the figure, an optimistic assumption of each test step estimates to uncover and

correct 50% of all incoming defects without adding any new defects. 10 preliminary

design errors are extended to 94 defects before testing start, and 12 latent errors are

released after the system testing. On the other hand, there are 24 defects before

testing stage commences in the defect amplification model with reviews are

conducted. Eventually, although there are 3 latent errors are released after the

system testing, it leaches the latent error more than the other up to 8 times. As a

consequence, a software development has to spend effort and time to manage the

formal technical review. Nevertheless, it provides a provable cost benefit (Pressman

2005, pp.753-754)
 The formal technical review is a software quality control activity which is

carried out by software engineers. Its objectives are uncovering defects in method,

logic, or implementation for any delegation of the software, verify that contribute to

compliant requirements, as well as, ensure that software has been represented

which is according to predefined standards. In addition, the objects of formal

technical review are to not only achieve software developed in a uniform style, but

also lead to project that more manageable. In terms of function of the formal

technical review, it plays as ‘a class of reviews including walkthroughs, inspections,

round-robin reviews, and other small group technical assessments of software’

(Pressman 2005, p.754). Pressman (2005) states that each the formal technical

review is managed by a small group meeting and will be completely, if the meeting

has proper planning, controlling, as well as, attending. In this regard, he further

suggests that every review meeting should tolerate these conditions.

…Between three and five people (typically) should be involved in the review,

advance preparation should occur but should require no more than two hours of

work for each person, and the duration of the review meeting should be less than

two hours… (Pressman 2005, pp.754-755)

Given these specifications, the formal technical review emphasizes a small and

specific part of the software development. At the end of the review stage, all people

who involve the group meeting must decide whether to accept the product without

further adjustment, as well as, accept the product provisionally or reject the product

because of severe defects.

 The next stage of the formal technical review meeting is the stage of review

reporting and record keeping. During the formal technical review process, the one

who records all topics which have been raised may be distributed the summary of

review at the end of the review meeting. This stage serves 2 purposes; for identifying

problem domains within the product, and providing the item checklist that should be

addressed. In the next step of the formal technical review reporting and record

keeping is the review guidelines which have to be established in advance, distributed

to all members who involve in the meeting. Porter and his colleagues outline the set

of major guidelines that the formal technical review should be followed.

…1. Review the product, not the producer

2. Set an agenda and maintain it.

3. Limit debate and rebuttal.

4. Enunciate problem areas, but do not attempt to solve every problem noted.

5. Take written notes.

6. Limit the number of participants and insist upon advance preparation.

7. Develop a checklist for each product that is likely to be reviewed.

8. Allocate resources and schedule time for FTRs.

9. Conduct meaningful training for all reviewers.

10. Review your early reviews… (Pressman 2005, 756)

In fact of real software projects, there are resources limited and time which is short in

software development. In the long run, despite not having resources and time, the

formal technical review should not be skipped.

It can be conclude that there are various serious defects which happen in the

early stages of software development due to the myth of software quality control.

Most software development believes that software quality is the activity that should

be concerned after code has been generated. In fact, the software quality should be

commenced since the analysis phase not after coding phase, as we can see at the

defect amplification model. Consequently, these techniques mentioned in this essay

are the most important method for leaching the big defects happen in the early

stages of software development process that any tool cannot do.

References

Pressman, R. S. 2005, SOFTWARE ENGINEERING A Practitioner’s Approach, 6th edn, McGraw-Hill,

Boston.

DeMarco, T. 1999, Management Can Make Quality (Im)possible, Cutter IT Summit, Boston.

Freedman, D.P., and Weinberg, G. M. 1990, Handbook of Walkthroughs, Inspections and Technical

Reviews, 3rd edn, Dorset House.

Glass, R. 1998, Defining Quality Intuitively, IEEE Software.

IBM Corporation 1981, Implementing Software Inspections, course notes, IBM Systems Sciences

Institute.

Software Engineering Standards 1994, IEEE Computer Society.

Porter, A., Siy, H., Toman, C.A. and Votta, L.G. 1995, An Experiment to Assess the Cost Benefits of

Code Inspections in Large Scale Software Development, ACM Press, Washington D.C.

Schulmeyer, G.C., and McManus, J.I. 1998, Handbook of Software Quality Assurance, 3rd edn,

Prentice-Hall.

McBride, T. 2011, Software Quality Process – Introduction [PowerPoint slides], slide. 43, Retrieved

March 2 2011, from University of Technology, Sydney, 49264 Software Quality Processes.