⚫

Module 5
Chapter -13

13.1 Introduction
we need to define the qualities required for a system. We need to judge the objectively whether
system meets the quality requirements and this needs to be measured.

13.2 The place for Software Quality in Project Planning

Quality is of concern at all stages of project planning and execution. Fig 13.1 shows the following
steps which are important.
Step 1 : Identify project scope and objectives : Some objectives related to the qualities of the
application development.
Step 2 : Identify project infrastructure : This identifies the installation standards and
procedures.
Step 3 : Analyze project characteristics: application to be implemented is examined to see if it
has any special quality requirements.
Step 4 : Identify the products and activities of the project : It is at this point of that the entry, exit
and process requirements identified for each activity.
Step 8: Review and publicize plan: At this stage the overall quality aspects of the project plan are
reviewed.

13.3 Importance of Software Quality

• Increasing criticality of software: The customer or user is anxious about the reliability of
the software. The organization relies more on their computer systems and software is used in
more safety-critical applications.
• The intangibility of software: This makes difficult to know that the tasks of the project
completed satisfactorily. It can be made tangible by demanding the developers to produce
deliverables and later they can be examined.
• Accumulating errors during software development: system development comprises of
steps and the errors from one step to another keep on accumulating in the deliverables
that are developed in later stages. So fixing errors become more expensive in the project and
debugging becomes difficult to control.
For these reasons quality management is an essential part of overall project management.

13.4 Defining Software Quality

Following details are required software quality specifications:

• Definition/description – definition of quality characteristics.

• Scale – the unit of measurement.
• Test – the practical test of the extent to which the attribute quality exists.
• Minimally acceptable – the worst value which might be acceptable, and below which the
product would have to be rejected.
• Target range – the range of values within which planned quality measurement value
should lie.
 • Now – the value that applies currently.
There could be several measurements applicable to quality characteristics.

• Availability – the percentage of a particular time interval that a system is usable.

• Mean time between failures – Total service time divided by the number of failures.
• Failure on demand – the probability that a system will not be available at the time
required.
• Support activity – the number of fault reports that are generated and processed.
• Maintainability – how quickly a fault once detected, can be corrected.
• Changeability – the ease with which the software can be modified.

13.5 Software Quality Models

Galvin’s quality demission:
Defines the quality of any product in terms of eight general attributes.

• Performance – how well it performs the jobs.

• Features – how well it supports the required features.
• Reliability – probability of a product working satisfactorily within a specific period of time.
• Conformance – degree to which the product meets the requirements.
• Durability – measure of the product’s life.
• Serviceability – speed and effectiveness maintenance.
• Aesthetics – the look and feel of the product.
• Perceived quality – user’s opinion about the product quality.

McCall Model
Defines the following eleven attributes of the software.

• Correctness – the extent to which a software product satisfies its specifications.

• Reliability – the probability of the software product working satisfactorily over a given
duration.
• Efficiency – the amount of computing resources required to perform the required
function.
• Integrity – the extent to which the data of the software product remains valid.
• Usability – the effort required to operate the software product.
• Maintainability – the ease with which it is possible to locate and fix bugs in the software
product.
• Flexibility – the effort required to adapt the software product to changing requirements.
• Testability – the effort required to test the software product to ensure that it performs its
intended function.
 • Portability – the effort required to transfer the software product from one hardware or
software system environment to another.
• Reusability – the extent to which a software can be reused in other applications.
• Interoperability – the effort required to integrate the software with other software.

Dromey’s model
Dromey’s hierarchical quality model is shown in fig 13.2. The model proposes four major high-
level properties of the software: Correctness, internal characteristics, contextual
characteristics and certain descriptive properties.

Boehm’s model
The quality of a software can be defined based on three high-level characteristics. These high-
level characteristics are:

• As-is utility – how well (easily, reliably and efficiently) can it be used?
• Maintainability – how easy it is to understand, modify and then retest the software?
• Portability – how difficult would it be to make the software in a changed environment?
Fig 13.3 shows the Boehm’s hierarchical quality model based on wider range of software
attributes with greater focus on maintainability.

13.7 Product and Process Metrics

• The developers can ensure the quality of a software product based on the measurement
of attributes called product and process metrics.
• Product metrics
measures the characteristics of a product being developed such as
✓ LOC (lines of code) and
✓ function point metrics used to measure the size.
✓ PM(person-month) metric used to measure effort required to develop a
product and time required to develop a product is measured in months.
• Process metrics
✓ Measures how a development process is performing. Examples of process
metrics are review effectiveness,
✓ average number of defects found per hour of inspection,
✓ average defect correction time,
✓ productivity,
✓ average number of failures during testing per LOC.

13.8 Product versus Process Quality Management

The system development process comprises of the following activities as shown in the fig 13.4.
Activities are linked so that output from one activity is input to next activity. Errors should be
eradicated by careful observation pf deliverables.
It can be done by using following process requirements steps.
Entry requirements:
Which is to be there before an activity starts. For example, set of test data and expected results
be prepared before testing activity starts.
Implementation requirements:
Defines how the process to be conducted. For example, whenever an error is found and
corrected, all test runs should be repeated.

Exit requirements:
Which have to be fulfilled before an activity is deemed to have been completed. For example, for
testing phase to be completed, all tests will have to be run successfully with no outstanding
errors.
⚫ Estimation of resources, cost, and schedule for a software engineering effort requires
experience.
⚫ Project complexity - Complexity, however, is a relative measure that is affected by familiarity
with past effort.
The first-time developer of a sophisticated e-commerce application might consider it to be
exceedingly complex. However, a Web engineering team developing its tenth e-commerce
WebApp would consider such work easy.
⚫ Project size is another important factor that can affect the accuracy and efficacy of
estimates. As size increases, the interdependency among various elements of the software
grows rapidly.
⚫ Problem decomposition, becomes more difficult because the refinement of problem
elements.
⚫ The degree of structural uncertainty also has an effect on estimation risk.
⚫ When comprehensive software metrics are available for past projects, estimates can
be made with greater assurance, schedules can be established to avoid past difficulties,
and overall risk is reduced.

⚫ Software cost and effort estimation will never be an exact science. Too many variables—
human, technical, environmental, political—can affect the ultimate cost of software and
effort applied to develop it.
⚫ To achieve reliable cost and effort estimates, a number of options arise:
1. Delay estimation until late in the project (obviously, we can achieve 100 percent accurate
estimates after the project is complete!).
2. Base estimates on similar projects that have already been completed.
3. Use relatively simple decomposition techniques to generate project cost and effort estimates.
4. Use one or more empirical models for software cost and effort estimation.
⚫ Unfortunately, the first option, however attractive, is not practical. Cost estimates must be
provided up-front.
⚫ The second option can work reasonably well, if the current project is quite similar to past
efforts and other project influences (e.g., the customer, business conditions, the software
engineering environment, deadlines) are roughly equivalent.
⚫ The remaining options are viable approaches to software project estimation. Ideally, the
techniques noted for each option should be applied in tandem; each used as a cross-check
for the other.
⚫ Decomposition techniques take a divide-and-conquer approach to software project
estimation. By decomposing a project into major functions and related software engineering
activities, cost and effort estimation can be performed in a stepwise fashion.
⚫ A model is based on experience (historical data) and takes the form
d = f (vi)
where d is one of a number of estimated values (e.g., effort, cost, project duration) and vi are
selected independent parameters (e.g., estimated LOC or FP).

⚫ The decomposition approach was discussed from two different points of view:
decomposition of the problem and decomposition of the process.
⚫ Estimation uses one or both forms of partitioning. But before an estimate can be made, you
must understand the scope of the software to be built and generate an estimate of its
“size.”

⚫ The accuracy of a software project estimate is predicated on a number of things:

(1) the degree to which you have properly estimated the size of the product to be built.
(2) the ability to translate the size estimate into human effort, calendar time, and dollars (a
function of the availability of reliable software metrics from past projects).
(3) the degree to which the project plan reflects the abilities of the software team; and
(4) the stability of product requirements and the environment that supports the software
engineering effort.
⚫ Putnam and Myers [Put92] suggest four different approaches to the sizing problem:
1. “Fuzzy logic” sizing. This approach uses the approximate reasoning techniques that are the
cornerstone of fuzzy logic. To apply this approach, the planner must identify the type of
application, establish its magnitude on a qualitative scale, and then refine the magnitude
within the original range.
2. Function point sizing. The planner develops estimates of the information
domain characteristics.
3. Standard component sizing. Software is composed of a number of different “standard
components” that are generic to a particular application area.
For example, the standard components for an information system are subsystems, modules,
screens, reports, interactive programs, batch programs, files, LOC, and object-level
instructions. The project planner estimates the number of occurrences of each standard
component and then uses historical project data to estimate the delivered size per standard
component.
4. Change sizing. This approach is used when a project encompasses the use of existing
software that must be modified in some way as part of a project. The planner estimates the
number and type (e.g., reuse, adding code, changing code, deleting code) of modifications that
must be accomplished.

⚫ LOC(Lines of Code) and FP(Function Points) are the estimation techniques used in project
estimation

⚫ They are used in two ways

⚫ as estimation variables to “size” each element of the software.

⚫ as baseline metrics collected from past projects and used in conjunction with estimation
variables to develop cost and effort projections.
⚫ Baseline productivity metrics (e.g., LOC/pm or FP/pm6) are then applied to the appropriate
estimation variable, and cost or effort for the function is derived.

⚫ Function estimates are combined to produce an overall estimate for the entire project.

⚫ In general, LOC/pm or FP/pm averages should be computed by project domain. That is,
projects should be grouped by team size, application area, complexity, and other relevant
parameters ( pm means- person months)

⚫ A three-point or expected value can then be computed. The expected value for the
estimation variable (size) S can be computed as a weighted average of the optimistic (sopt),
most likely (sm), and pessimistic (spess) estimates. For example,
⚫ The most common technique for estimating a project is to base the estimate on the process
that will be used. That is, the process is decomposed into a relatively small set of tasks and the
effort required to accomplish each task is estimated.
⚫ Once problem functions and process activities are melded, you estimate the effort (e.g.,
person-months) that will be required to accomplish each software process activity for each
software function. These data constitute the central matrix of the table in Figure 26.4.

⚫ Average labor rates (i.e., cost/unit effort) are then applied to the effort estimated for each
process activity. It is very likely the labor rate will vary for each task. Senior staff are heavily
involved in early framework activities and are generally more expensive than junior staff
involved in construction and release.

Developing an estimation approach with use cases is problematic for the following reasons.

⚫ Use cases are described using many different formats and styles—there is no standard form.

⚫ Use cases represent an external view (the user’s view) of the software and can therefore be
written at many different levels of abstraction.

⚫ Use cases do not address the complexity of the functions and features that are described.

⚫ Use cases can describe complex behavior (e.g., interactions) that involve many functions and
features.

⚫ Smith argues that any level of this structural hierarchy can be described by no more than 10
use cases. Each of these use cases would encompass no more than 30 distinct scenarios.

⚫ Obviously, use cases that describe a large system are written at a much higher level of
abstraction (and represent considerably more development effort) than use cases that are
written to describe a single subsystem

⚫ Therefore before use cases can be used for estimation,

❖ the level within the structural hierarchy is established,

❖ the average length (in pages) of each use case is determined,

❖ the type of software (e.g., real-time, business, engineering/scientific, WebApp, embedded)

is defined,

❖ and a rough architecture for the system is considered.