McCall's Quality Model - 1977 - WordPress.com

idiotcanvasSecurity

Nov 17, 2013 (3 years and 10 months ago)

151 views


1

UNIT
-
I


F
U
N
D
A
M
E
N
T
A
LS

O
F

S
O
F
T
W
A
R
E

Q
U
A
L
I
T
Y

E
N
G
I
N
EE
R
I
N
G


CONCEPTS OF QUALITY


Definition of Quality:

The
totality of features and characteristics of a product/service that bear on

its
ability
to satisfy specified/implied needs.
Quality
is the totality of
features and
characteristics of a product that bears on it’s ability to satisfy the stated or
implied needs
--
ASQC


Quality:


Ability of the product/service to fulfill its function


Hard to define


Impossible to measure


Easy to recognize in its absen
ce

Transparent when present

Characteristics of Quality:


Quality is not absolute


Quality is multidimensional


Quality is subject to constraints


2


Quality is about acceptable compromises


Quality criteria are not independent, but interact with each o
ther

causing
conflicts

DIMENSIONS OF QUALITY



Performance



Aesthetics



Special features: convenience, high tech



Safety



Reliability



Durability



Perceived Quality



Service after sale

IMPORTANCE OF QUALITY



Lower costs (less labor, rework, scrap)



Motivated
employees



Market Share



Reputation



International competitiveness



Revenues generation increased (ultimate goal
)

SOFTWARE QUALITY FACTORS

A software quality factor is a non
-
functional requirement for a software
program which is not called up by the customer's

contract, but nevertheless is a
desirable requirement which enhances the quality of the software program.

Understandability

Completeness


3

Maintainability

Conciseness

Portability

Consistency

Testability

Usability

Reliability

Structured ness

Efficiency

Security


HIERARCHICAL MODEL OF QUALITY:



To compare quality in different situations, both qualitatively and
quantitatively, it is necessary to establish a model of quality.

Many model suggested for quality.

Most are hierarchical in nature.



A quantitative
assessment is generally made, along with a more



quantified assessment
.

Two principal models of this type, one by

Boehm (1978)

and

one by

McCall in 1977
.

A hierarchical model of software quality is

based upon a set of
quality criteria, each of which has a

set of

measures or metrics associated with
it.



4

The issues relating to the criteria of quality are

What criteria of quality should be employed?


How do they inter
-
relate?


How may the associated metrics be combined into a

meaningful overall
measure of Qua
lity?

THE HIERARCHICAL MODELS OF BOEHM AND MCCALL


THE GE MODEL (MCCALL, 1977 AND 1980)

This model was first proposed by McCall in 1977.


It was later revised as the MQ model, and it is aimed by system


developers to be used during the development
process


In early attempt to bridge the gap between users and

developers, the criteria
were chosen in an attempt to reflect

user’ s views as well as developer’ s
priorities.


The criteria appear to be technically oriented, but they are

described by a
series of questions which define
them in terms to non specialist
managers.


The three areas addressed by McCall’ s model (1977)

Product operation

:
requires that it can be learnt easily, operated


efficiently And it results are those requir
ed by the users.


5

Product revision

:
it is concerned with error correction and


adaptation Of the system and it is most costly part of software

development.

Product transition

: it is an important application and it is

distributed processing and the rapid

rate of

change in hardware is

Likely to increase.



Quality Models

_ Why a quality model?

_ Enables quality comparison both qualitatively and

quantitatively

_ Hierarchical models

_ considers quality under a series of quality characteristics

or criteria,
each having a set of associated measures or

metrics


_ combined in a hierarchical nature into an overall

assessment of quality

_ Questions


what criteria should be employed?


how do they inter
-
relate?


how can they be combined to provide an overall assessm
ent of quality?


6









7




McCall’s Model



Boehm’s Model

Barry W. Boehm

is known for his many contributions to software engineering.
He was the first to identify software as the primary expense of future computer
systems; he developed
COCOMO
, the
spiral model
,
wideband Delphi
, and many
more contributions through his involvement in industry and academia.



8



M
cCall’ s criteria of quality defined


Efficiency

is concerned with the use of resources e.g.

processor time,
storage.

It falls into two categories: execution efficiency and storage efficiency

Integrity

is the protection of the program from

unauthorized access.

Correctness

is the extent to which a program fulfils its

specification.

Reliability

is its ability not to fail.


Maintainability

is the effort required to locate and fix a

fault in the
program within its operating environment.

F
lexibility

is the ease of making changes required by

changes in the
operating environme
nt


9

Testability

is the ease of testing the programs, to ensure

that it is error
-
free and meet its specification.

Portability

is the effort required to transfer a progr
am

from one
environment to another.

Reusability

is the ease of refusing software in a different

context.

Interoperability

is the effort required to couple the


system to another system.






10

McCall's Quality Model
-

1977


Jim McCall produced this model for the US Air Force and the intention was to
bridge the gap between users and developers. He tried to map the user view with
the developer's priority.


McCall identified three main perspectives for characterizing the qualit
y
attributes of a software product.


These perspectives are:
-






Product revision


The product re
vision perspective identifies quality factors that influence the
ability to change the software product, these factors are:
-




business.



Product

transition


The product transition perspective identifies quality factors that influence the
ability to adapt the software to new environments:
-



11

bility to transfer the software from one environment to
another.

context.

together.


Product
operations


The product operations perspective identifies quality factors that influence the
extent to which the software fulfils its specification:
-



tem fails.





In total McCall identified the 11 quality factors broken down by the 3
perspectives,
as listed above.

For each quality factor McCall defined one or more quality criteria (a way of
measurement), in this way an overall quality assessment could be made of a
given software product by evaluating the criteria for each factor.

For example the
M
aintainability

quality factor would have criteria of
simplicity, conciseness and modularity
.

Boehm's Quality Model
-

1978


12

Barry W. Boehm also defined a hierarchical model of software quality
characteristics, in trying to qualitatively define software qual
ity as a set of
attributes and metrics (measurements).


At the highest level of his model, Boehm defined three primary uses (or basic
software requirements), these three primary uses are:
-


As
-
is utility
, the extent to which the as
-
is software can be u
sed (i.e. ease of
use, reliability and efficiency).

Maintainability
, ease of identifying what needs to be changed as well as
ease of modification and retesting.

Portability
, ease of changing software to accommodate a new environment.


These three
primary uses

had quality factors associated with them , representing
the next level of Boehm's hierarchical model.


Boehm identified seven quality factors, namely:
-


computer confi
gurations (i.e. operating systems, databases etc.).

absence of defects.





13

with regard to purpose and structure.



These quality factors are further broken down into
Primitive constructs

that can
be measured, for example
Testability

is broken down into:
-

accessibility,
communicativeness,
structure and self descriptiveness. As with McCall's
Quality Model, the intention is to be able to
measure

the lowest level of the
model.

-
defined, well
-
differ
entiated characteristics of
software quality.


so that quality criteria are subdivided.

or ‘ as is’ and the util
ities are a subtype of the general utilities, to the product
operation.

further split into primitive characteristics which are amenable to measurement.

on a much larger set of criteria than McCall’ s model,
but retains the same emphasis on technical criteria.

SUMMARY OF THE TWO MODELS

Although only a summary of the two example software factor models has been
given, some comparisons and observations can b
e made that generalize the
overall quest to characterize software.


14


Both of McCall and Boehm models follow a similar structure, with a similar
purpose. They both attempt to breakdown the software artifact into constructs
that can be measured. Some quality

factors are repeated, for example: usability,
portability, efficiency and reliability.


The presence of more or less factors is not, however, indicative of a better or
worse model.


The value of these, and other models, is purely a pragmatic one and not

in the
semantics or structural differences.

The extent to which one model allows for an accurate measurement (cost and
benefit) of the software will determine its value.


It is unlikely that one model will emerge as
best

and there is always likely to be

other models proposed, this reflects the intangible nature of software and the
essential difficulties that this brings. The
ISO 9126

represents the ISO's recent
attempt to define a set of useful quality char
acteristics.




The two models share a number of common characteristics

are:
-


The quality criteria are supposedly based upon the
user’

s view.


The models focus on the parts that designers can more readily analyze.


Hierarchical models cannot be tested or validated.

It

cannot be shown that

the metrics accurately reflect

the criteria.



15


The measurement of overall quality is achieved by a

weighted summation of the characteristics.

Boehm talks of modifiability
where McCall distinguishes

expandability
from adaptability and documentation, understandability

and clarity.


HOW THE QUALITY CRITERIA INTERRELATE


The individual measure of software quality provided do not

provide an
over all measure of software quality.

The individual measures must be combined.



The individual measures of quality may conflict with each

other.


Some of these relationships are described below;

Integrity vs. efficiency (inverse)

the con
trol of

access to data or software
requires additional code

and processing leading to a longer runtime and

additional storage requirement.



Usability vs. efficiency (inverse)

Improvements in

the human /
computer interface may significantly increase the
amount of code and power
required

Maintainability and testability vs. efficiency

(inverse)

Optimized and
compact code is not easy

to maintain.

Portability vs. efficiency (inverse)

the use of

optimized software or
system utilities will lead to decrease i
n probability.


16

Flexibility, reusability and interoperability vs.

efficiency

(inverse) the
generally required for a


flexible system, the use if interface routines and the

modularity desirable for reusability will all decrease

efficiency.


Flexibility an
d reusability vs. integrity (inverse)

the general flexible data
structures required for

flexible and reusable software increase the security

and
protection problem.


Interoperability vs. integrity (inverse)
C oupl

e d
system allow more avenues
of access to more and different users.


Reusability vs. reliability (inverse)
reusable

software is required to be
general: maintaining

accuracy and error tolerance across all cases

is

difficult.


Maintainability vs. flexibility
(direct)
mai

nt

ain

abl

e
code arises from code
that is well structured.

Maintainability

vs.
reusability (direct)



Well
structured easily maintainable code is easier to reuse

in other programs either as a library of routines or as

code placed directly with
in another program.

Portability vs. reusability (direct)

portable code is


likely to be free of environment
-
specific features

Correctness vs. efficiency
(neutral)

the correctness

of code, i.e. its conformance to specification does
not

influence its
efficiency

Process Maturity / Capability Maturity

The concepts of process or capability maturity are increasingly being applied to
many aspects of product development, both as a means of assessment and as

17

part of a framework for improvement. Maturity mode
ls have been proposed for
a range of activities including quality management, software development,
supplier relationships, R&D effectiveness, product development, innovation,
product design, product development collaboration and product reliability.

The principal idea of the maturity grid is that it describes in a few phrases, the
typical behaviour exhibited by a firm at a number of levels of ‘maturity’, for
each of several aspects of the area under study. This provides the opportunity to
codify what
might be regarded as good practice (and bad practice), along with
some intermediate or transitional stages.

This page traces the origins of the maturity grid and reviews methods of
construction and application. It draws on insights gained during developme
nt of
maturity grids for product design and for the management of product
development collaborations, and discusses alternative definitions of 'maturity'.

One conclusion is that it is difficult to make the maturity grid development
process completely rigor
ous and it is suggested that some compromise is
necessary and appropriate in the interests of producing a useful and usable tool.

Origins and overview of maturity approaches

Maturity approaches have their roots in the field of quality management. One of
t
he earliest of these is Crosby's Quality Management Maturity Grid (QMMG)
which describes the typical behaviour exhibited by a firm at five levels of
‘maturity’, for each of six aspects of quality management (see Fig. 1). The
QMMG had a strong evolutionary
theme, suggesting that companies were likely
to evolve through five phases
-

Uncertainty, Awakening, Enlightenment,
Wisdom, and Certainty


in their ascent to quality management excellence.

Measurem
Stage I:

Stage II:

Stage III:

Stage IV:

Stage V:


18

ent
Categories

Uncertainty

Awakening

Enlightenm
ent

Wisdom

Certainty

Manageme
nt
understand
ing

and
attitude

No
comprehen
sion of
quality as a
manageme
nt tool.
Tend to
blame
quality
department
for "quality
problems"

Recognisin
g that
quality
manageme
nt may be
of v
alue
but not
willing to
provide
money or
time to
make it
happen.

While going
through
quality
improvemen
t program
learn more
about
quality
managemen
t; becoming
supportive
and helpful.

Participati
ng.
Understan
d
absolutes
of quality
manageme
nt.
Recognise
their
personal
role in
continuing
emphasis.

Consider
quality
managem
ent an
essential
part of
company
system.

Quality
organisatio
n

status

Quality is
hidden in
manufacturi
ng or
engineering
department
s.
Inspection
probably
A stronger
quality
leader is
appointed
but main
emphasis is
still on
appraisal
and
Quality
Department
reports to
top
managemen
t, all
appraisal is
incorporate
d and
Quality
manager is
an officer
of
company;
effective
status
reporting
and
Quality
manager
on board
of
directors.
Preventio
n is main
concern.
Quali
ty is

19

not part of
organisatio
n. Emphasis
on appraisal
and sorting.

moving the
product.
Still part of
manufactu
ring or
other.

manager
h
as role in
managemen
t of
company.

preventati
ve action.
Involved
with
consumer
affairs and
special
assignmen
ts.

a thought
leader.

Problem
handling

Problems
are fought
as they
occur; no
resolution;
inadequate
definition;
lots of
yelling and
accusations

Teams are
set up to
attack
major
problems.
Long
-
range
solutions
are not
solicited.

Corrective
action
communic
at
ion
established.
Problems
are faced
openly and
resolved in
an orderly
way.

Problems
are
identified
early in
their
developme
nt. All
functions
are open
to
suggestion
and
improvem
ent.

Except in
the most
unusual
cases,
problems
are
prevented
.

Cost of
quality as
Reported:
unknown

Reported:
3%

Reported:
8%

Reported:
6.5%

Reported:
2.5%


20

% of sales

Actual: 20%

Actual:
18%

Actual: 12%

Actual: 8%

Actual:
2.5%

Quality
improveme
nt

actions

No
organised
activities.
No
understandi
ng of such
activities.

Trying
obvious
"motivatio
nal" short
-
range
efforts.

Implementa
tion of the
14
-
step
program
with
thorough
understandi
ng and
establishme
nt of each
step.

Continuing
the 14
-
step
program
and
starting
Make
Certain

Quality
improvem
ent is a
normal
and
continued
act
ivity.

Summation
of
company
quality
posture

"We don't
know why
we have
problems
with
quality"

"Is it
absolutely
necessary
to always
have
problems
with
quality?"

"Through
managemen
t
commitmen
t and quality
improvemen
t we are
identifying
and
resolving
our
"Defect
prevention
is a routine
part of our
operation"

"We know
why we
do not
have
problems
with
quality"


21

problems"

Figure 1: Crosby's Quality Management Maturity Grid (QMMG)


Perhaps the best known derivative from this line of work is the Capability
Matu
rity Model (CMM) for software. The CMM takes a different approach
however, identifying instead a cumulative set of ‘key process areas’ (KPAs)
which all need to be performed as the maturity level increases. As an alternative
to the complexity of CMM
-
derived

maturity models, others have built on the
Crosby grid approach, where performance of a number of key activities are
described at each of 4 levels.



Level

Description

Process areas

Optimising

Continuous process improvement is
enabled by quantitative
feedback
from the process and from piloting
innovative ideas and technologies

∙ Defect Prevention

∙ Technology Change
Management

∙ Process Change
Management

Managed

Detailed measures of the software
process and product quality are
collected. Both the software
process and products are
quantitatively understood and
∙ Quantitative
Process
Management

∙ Software Quality
Management


22

controlled.

Defined

The software process
for both
management and engineering
activities is documented,
standardised, and integrated into a
standard software process for the
organisation. All projects use an
approved, tailored version of the
organisation's standard software
process for developing
and
maintaining software

∙ Organization
Process Focus

∙ Organization
Process Definition

∙ Training Program

∙ Integrated Software
Management

∙ Software Product
Engineering

∙ Intergroup
Coordination

∙ Peer Reviews

Repeatable

Basic project management
proces
ses are established to track
cost, schedule, and functionality.
The necessary process discipline is
in place to repeat earlier successes
on projects with similar
applications

∙ Requirements
Management

∙ Software Project
Planning

∙ Software Project
Tracking

and
Oversight

∙ Software
Subcontract
Management

∙ Software Quality

23

Assurance

∙ Software
Configuration
Management

Initial

The software process is
characterised as ad hoc, and
occasionally even chaotic. Few
processes are defined, and success
depends on ind
ividual effort and
heroics

∙ no required
processes

Maturity levels and process areas of the Software CMM


Typology

What is maturity? The literal meaning of the word maturity is 'ripeness',
conveying the notion of development from some initial state to some more
advanced state. Implicit in this is the notion of evolution or ageing, suggesting
that the subject may pass t
hrough a number of intermediate states on the way to
maturity.

Although a number of different types of maturity model have been proposed
(see Fig. 3), they share the common property of defining a number of
dimensions or process areas at several discrete s
tages or levels of maturity, with
a description of characteristic performance at various levels of granularity.

The various components which may or may not be present in each model are:



a number of levels (typically 3
-
6)


24



a descriptor for each level (such
as initial / repeatable / defined /
managed / optimising)



a generic description or summary of the characteristics of each level as a
whole



a number of dimensions or 'process areas'



a number of elements or activities for each process area



a description of
each activity as it might be performed at each maturity
level

The number of levels is to some extent arbitrary. One key aspect of the Quality
Grid approach is that it provides descriptive text for the characteristics traits of
performance at each level. Th
is becomes increasingly difficult as the number of
levels is increased, and adds to the complexity of the tool, such that descriptive
grids typically contain no more than 5 levels.


A sample of maturity models, showing range of subject and architecture


A distinction is made between those models in which different activities may
be scored to be at different levels, and those in which maturity levels are
'inclusive', where a cumul
ative number of activities must all be performed. In

25

the terminology of the SEI CMM, this is referred to as 'continuous' and 'staged'
respectively.

A typology is proposed here which divides maturity models into three basic
groups:



Maturity grids



Hybrids an
d Likert
-
like questionnaires



CMM
-
like models

If there has been no improvement since the beginning of your relationship with
your SEO company, they need to explain why. Then you have a great
seo
Company

working fo
r you. If you don't want to do it yourself, an SEO company
being paid monthly should detail exactly what they are doing for you. | Any link
exchanges promising hundreds or links immediately upon joining should be
avoided unless the only search engine you c
are about is MSN. Using a
link
exchange

as the only way you get links will also not be a path you want to
wander down. Exchanging links with every site under the sun is also bad.

The Likert
-
like qu
estionnaire, when constructed in a particular way, can be
considered to be a simple form of maturity model. In this case, the 'question' is
simply a statement of 'good practice' and the respondent is asked to score the
relative performance of the organisat
ion on a scale from 1 to n. This is
equivalent to a maturity grid in which only the characteristics of the top level
are described. Note that if n=2, this form of instrument becomes a checklist.
Models combining a questionnaire approach with definitions of

maturity are
referred to here as 'hybrids'. Typically, there is an overall description of the
levels of maturity, but no additional description for each activity.


26

CMM
-
like models define a number of key process areas at each level. Each key
process area is

organised into five sections called 'common features'
-

commitment to perform, ability to perform, activities performed, measurement
& analysis and verifying implementation. The common features specify the key
practices that, when collectively addressed,
accomplish the goals of the key
process area. These models are typically rather verbose.

Application

We have developed maturity grids for product design and for the management
of product development collaborations, and these have been applied both
standalo
ne and in workshop settings. The grids were found to be a useful way of
capturing good and not
-
so
-
good practice, but in the interests of usability, a
balance was necessary between richness of detail (verbosity) and conciseness
(superficiality).

Chiesa et
al. produced two instruments as part of a technical innovation audit: a
simple maturity
-
grid ‘scorecard’ and a more detailed ‘self
-
evaluation’. Even
though the self
-
evaluation was less onerous than CMM
-
based procedures, they
report that companies still pre
ferred the simplicity of the scorecard.

Maturity assessments can be performed by an external auditor, or by self
-
assessment. Whilst self
-
assessments can be performed by an individual in
isolation, they are perhaps more beneficial if approached as a team ex
ercise.
One reason for this is to eliminate single
-
respondent bias. Also, by involving
people from different functional groups within a project team, the assessment
has a cross
-
functional perspective and provides opportunity for consensus and
team
-
building
.

Other studies have confirmed the value of team discussion around an audit tool.
Discussing their innovation audit tool, Chiesa et al. report that ‘the feedback on

27

team use was very positive’. Group discussion also plays a part in use of
Cooper’s NewProd
system, while Ernst and Teichert recommend using a
workshop in an NPD benchmarking exercise to build consensus and overcome
single
-
informant bias.

According to the software CMM,

"Software process maturity is the extent to which a specific process is
expli
citly defined, managed, measured, controlled, and effective."

Furthermore, maturity implies that the process is well
-
understood, supported by
documentation and training, is consistently applied in projects throughout the
organisation, and is continually be
ing monitored and improved by its users:

"Institutionalization entails building an infrastructure and a corporate culture
that supports the methods, practices, and procedures of the business so that
they endure after those who originally defined them have
gone".

The CMM identifies five levels of maturity: initial, repeatable, defined,
managed and optimizing. Dooley points out that the CMM maturity definition
mixes process attributes (defined, managed, measured, controlled) with
outcomes (effective), and pro
poses an alternative definition of maturity:

"T
he extent to which a process is explicitly defined, managed, measured, and
continuously improved".

This is a logical modification, but raises an interesting issue: is the inclusion of
'effective' in the CMM de
finition of maturity a caveat, acknowledging that
defined, managed, measured and controlled may not be enough? Moreover, can
an ineffective process be described as mature even if it is defined, managed
measured and controlled? Perhaps the key aspects of ma
turity might be better

28

defined as effective AND institutionalised (i.e. repeatable), regardless of the
degree of management or bureaucracy associated with it.

Our current working definition is shown below:

"The degree to which processes and activities are
executed following 'good
practice' principles and are defined, managed and repeatable."

A synthesis of maturity levels is shown in Fig. 4, which represents maturity as a
combination of the presence of a process and the organization’s attitude to it.
The
lowest level is characterized by ad hoc behavior. As the level increases, the
process is defined and respected. At the highest level, good practice becomes
ingrained or 'cultural', and it could be said that whilst the process exists, it is not
needed.

****
**************

UN
I
T

I
I

D
EVE
L
O
P
M
E
N
T
S

I
N
M
E
A
S
U
R
I
N
G

Q
U
A
L
I
T
Y

Selecting Quality Goals And Measures

What is software quality, and why is it so important that it is pervasive in the Software Engineering
Body of Knowledge? Within an information system, software
is a tool, and tools have to be selected
for quality and for appropriateness. That is the role of requirements. But software is more than a
tool. It dictates the performance of the system, and it is therefore important to the system quality.

The notion of
“quality” is not as simple as it may seem. For any engineered product, there are many
desired qualities relevant to a particular project, to be discussed and determined at the time that the
product requirements are determined. Qualities may be present or a
bsent, or may be matters of
degree, with tradeoffs among them, with practicality and cost as major considerations. The software
engineer has a responsibility to elicit the system’s quality requirements that may not be explicit at
the outset and to discuss
their importance and the difficulty of attaining them. All processes

29

associated with software quality (e.g. building, checking, improving quality) will be designed with
these in mind and carry costs based on the design. Thus, it is important to have in min
d some of the
possible attributes of quality.

Software Quality Fundamentals

Agreement on quality requirements, as well as clear communication to the software engineer on
what constitutes quality, require that the many aspects of quality be formally defined

and
discussed.A software engineer should understand the underlying meanings of quality concepts and
characteristics and their value to the software under development or to maintenance.

The important concept is that the software requirements define the req
uired quality characteristics
of the software and influence the measurement methods and acceptance criteria for assessing these
characteristics.

Software Engineering Culture and Ethics

Software engineers are expected to share a commitment to software quali
ty as part of their culture.
Ethics can play a significant role in software quality, the culture, and the attitudes of software
engineers. The IEEE Computer Society and the ACM have developed a code of ethics and
professional practice based on eight princi
ples to help software engineers reinforce attitudes related
to quality and to the independence of their work.

Value and Costs of Quality

The notion of “quality” is not as simple as it may seem. For any engineered product, there are many
desired qualities
relevant to a particular perspective of the product, to be discussed and determined
at the time that the product requirements are set down. Quality characteristics may be required or
not, or may be required to a greater or lesser degree, and trade
-
offs may

be made among them.

The cost of quality can be differentiated into prevention cost, appraisal cost, internal failure cost,
and external failure cost. A motivation behind a software project is the desire to create software that
has value, and this value ma
y or may not be quantified as a cost. The customer will have some
maximum cost in mind, in return for which it is expected that the basic purpose of the software will
be fulfilled. The customer may also have some expectation as to the quality of the softwa
re.
Sometimes customers may not have thought through the quality issues or their related costs. Is the
characteristic merely decorative, or is it essential to the software? If the answer lies somewhere in

30

between, as is almost always the case, it is a matt
er of making the customer a part of the decision
process and fully aware of both costs and benefits. Ideally, most of these decisions will be made in
the software requirements process, but these issues may arise throughout the software life cycle.
There is

no definite rule as to how these decisions should be made, but the software engineer
should be able to present quality alternatives and their costs.



















31




Quality function deployment (QFD)

INTRODUCTION


The Quality Function Deployment (QFD) philosophy was pioneered by Yoji
Akao and Shigeru Mizuno. It aims to design products that assure customer satisfaction and
value
-

the first time, every time.


The QFD framework

can be used for translating actual customer statements and needs
("The voice of the customer") into actions and designs to build and deliver a quality product .


Quality function deployment (QFD) is a “method to transform user demands i
nto design
quality, to deploy the functions forming quality, and to deploy methods for achieving the design
quality into subsystems and component parts, and ultimately to specific elements of the
manufacturing process.”


QFD is designed

to help planners focus on characteristics of a new or existing
product or service from the viewpoints of maarket segments, company, or technology
-
development needs. The technique yields graphs and matrices.


QFD helps transform custome
r needs (the voice of the customer {VOC}) into engineering
characteristics (and appropriate test methods) for a product or service, prioritizing each product or
service characteristic while simultaneously setting development targets for product or service
.



Quality Function Deployment (QFD) was developed to bring this
personal interface to modern manufacturing and business. In today's industrial
society, where the growing distance between producers and users is a concern, QFD
links the needs of the custom
er (end user) with design, development, engineering,
manufacturing, and service functions.

In Short QFD is:

1.

Understanding Customer Requirements


32

2.

Quality Systems Thinking + Psychology + Knowledge/Epistemology

3.

Maximizing Positive Quality That Adds Value

4.

Comprehensive Quality System for Customer Satisfaction

5.

Strategy to Stay Ahead of The Game

Typical

tools and techniques
used within QFD include:



Affinity Diagrams
. To surface the "deep structure" of voiced
customer requirements.



Relations Diagrams
. To di
scover priorities and root causes of
process problems and unspoken customer requirements.



Hierarchy Trees
. To check for missing data and other purposes.



Various Matrixes
. For documenting relationships, prioritization and
responsibility.



Process Decision

Program Diagrams.

To analyze potential failures of
new processes and services.



Analytic Hierarchy Process
. To prioritize a set of requirements, and
to select from alternatives to meet those requirements.



Blueprinting.

To depict and analyze all the processes which are
involved in providing a product or service.



House of Quality
.

STEPS IN QUALITY FUNCTION DEPLOYMENT PROCESS

Typically, a QFD process has the following stages:

1.

Derive top
-
level product requirements or tech
nical characteristics from customer
needs, using the Product Planning Matrix.

2.

Develop product concepts to satisfy these requirements.

3.

Evaluate product concepts to select the most optimal concept, using the Concept
Selection Matrix.

4.

Partition the system
concept or architecture into subsystems or assemblies, and
transfer the higher
-
level requirements or technical characteristics to these subsystems or
assemblies.

5.

Derive lower
-
level product requirements (assembly or part characteristics) and
specifications from subsystem/assembly requirements (Assembly/Part Deployment Matrix).


33

6.

For critical assemblies or parts, derive lower
-
level product requirements (assembly
or pa
rt characteristics) into the process planning.

7.

Determine manufacturing process steps that correspond to these assembly or part
characteristics.

8.

Based on these process steps, determine set
-
up requirements, process controls and
quality controls to assure t
he achievement of these critical assembly or part characteristics.

CONDITIONS OF QUALITY FUNCTION DEPLOYMENT:
-



The market survey results are accurate.



Customer needs cannot be documented and captured and they remain stable during
the whole process
.



BEN
EFITS OF THE QUALITY FUNCTION DEPLOYMENT MODEL:
-



Quality Function Deployment has the following benefits:
-







QFD seeks out both “spoken” and “unspoken” customer requirements and
maximizes “positive ” quality (such as ease of use, fun, luxury) that cr
eates value. Traditional
quality systems aim at minimizing negative quality (such as defects, poor service).



Instead of conventional design processes that focus more on engineering capabilities
and less on customer needs, QFD focuses all product developme
nt activities on customer
needs.



QFD makes invisible requirements and strategic advantages visible. This allows a
company to prioritize and deliver on them.



Reduced time to market.



Reduction in design changes.



Decreased design and manufacturing costs.



Improved quality.



Increased customer satisfaction.


THE MAIN BENEFITS OF QFD ARE(IN SHORT)



Improved Customer Satisfaction



Reduced Development Time


34



Improved Internal Communications



Better Documentation of Key Issues



Save Money

SOME ADDITIONAL
BENEFITS ARE:



Improved morale, organizational harmony



Improved efficiency



Reduction in design changes



Increased competitiveness



High market acceptance



Problems are easier to identify

DISADVANTAGES OF QUALITY FUNCTION DEPLOYMENT:
-



T
he following are the
disadvantages of quality function deployment :
-



As with other Japanese management techniques, some problems can occur when
we apply QFD within the western business environment and culture.



Customer perceptions are found by market survey. If the survey is
performed in a
poor way, then the whole analysis may result in doing harm to the firm.



The needs and wants of customers can change quickly nowadays. Comprehensive
system
-

and methodical thinking can make adapting to changed market needs more
complex.


APPLICATIONS OF THE QUALITY FUNCTION DEPLOYMENT METHOD:
-


The following are the Applications of the quality function deployment method:
-




To prioritize customer demands and customer needs. Spoken and unspoken;



Translating these needs into actions and des
igns such as technical characteristics
and specifications; and



To build and deliver a quality product or service, by focusing various business
functions toward achieving a common goal of customer satisfaction.


35

QFD has been applied in any industry: aerosp
ace, manufacturing, software, communication, IT,
chemical and pharmaceutical, transportation, defense, government, R&D, food, and service industry.

QFD SUMMARY



Orderly Way Of Obtaining Information & Presenting It



Shorter Product Development Cycle



Considera
bly Reduced Start
-
Up Costs



Fewer Engineering Changes



Reduced Chance Of Oversights During Design Process



Environment Of Teamwork



Consensus Decisions



Preserves Everything In Writing






Quality function deployment (QFD)

is a “method to transform user demands into design quality, to
deploy the functions forming quality, and to deploy methods for achieving the design quality into
subsystems and component parts, and ultimately to specific elements of the manufacturing
proce
ss.” QFD is designed to help planners focus on characteristics of a new or existing product or
service from the viewpoints of
market segments
, company, or technology
-
developmen
t needs. The
technique yields
graphs

and
matrices
.

QFD helps transform
customer

needs

(the
voice of the customer

[VOC]) into
engineering

characteristics (and appropriate
test methods
) for a product or service, prioritizing each product or
service chara
cteristic while simultaneously setting development targets for product or service.


+
VOICE OF THE
CUSTOMER
QFD
=
CUSTOMER
SATISFACTION

36






QFD


HISTORY




QFD LIFE CYCLE CONSIDERATIONS



QFD
Process



SQFD Process

TRADITIONAL QFD PHASES


SQFD PROCESS

QFD
STATISTICAL
PROCESS CONTROL
DESIGN QUALITY
VALUE
ENGINEERING

37


This diagram represents the QFD House of Quality concepts applied to requirements engineering, or
SQFD. “SQFD is a front
-
end requirements elicitation technique, adaptable to any software
enginee
ring methodology, that quantifiably solicits and defines critical customer requirements”
[Haag, 1996].

Step 1


Customer requirements are solicited and recorded

Step 2


Customer requirements are converted to technical and measurable statements and
recorde
d

Step 3


Customers identify the correlations between technical requirements and their own
verbatim statements of requirement

Step 4


Customer requirement priorities are established

Step 5


Applying weights and priorities to determine the technical prod
uct specification priorities
(this is a calculation)

QFD MATRIX



38

QFD Matrix
Absolute Weight and Percent
Prioritized Technical
Descriptors
Degree of Technical Difficulty
Relative Weight and Percent
Target Value
Customer
Requirements
Prioritized
Customer
Requirements
Technical
Descriptors
Primary
Primary
Secondary
Secondary
Technical
Competitive
Assessment
Customer
Competitive
Assessment
Our
A

s
B

s
Customer Importance
Target Value
Scale
-
up Factor
Sales Point
Absolute Weight
Our
A

s
B

s
Relationship between
Customer Requirements
and
Technical Descriptors
WHATs
vs.
HOWs
Strong
Medium
Weak
+9
+3
+1
Strong Positive
Positive
Negative
Strong Negative
+9
+3
-
3
-
9
Interrelationship between
Technical Descriptors
(correlation matrix)
HOWs
vs.
HOWs

QFD PROCESS

QFD Process
WHATs
HOW
MUCH
HOWs
WHATs
HOW
MUCH
HOWs

Phase

I

Product Planning


39

Phase I
Product Planning
Design
Requirements
Customer
Requirements

PHASE II

PART DEVELOPMENT

Phase II
Part Development
Part Quality
Characteristics
Design
Requirements




40

Phase III
Process Planning
Key Process
Operations
Part Quality
Characteristics

Phase IV
Production Planning
Production
Requirements
Key Process
Operations
Production Launch

QUALITY CHARACTERISTICS TREE


The quality characteristics are used as the targets for validation (external
quality) and
verification (internal quality) at the various stages of development.


41

They are refined into sub
-
characteristics, until the attributes or measurable properties are obtained.

In this context, metric or measure is a defined as a measurement metho
d and measurement means
to use a metric or measure to assign a value.


In order to monitor and control software quality during the development process, the
external quality requirements are translated or transferred into the requirements of intermediate
pr
oducts, obtained from development activities. The translation and selection of the attributes is a
non
-
trivial activity, depending on the stakeholder personal experience, unless the organization
provides an

infrastructure to collect and to analyze previous

experience on completed projects


A
requirement

is defined as "a condition or capability to which a system must conform".

There are many different kinds of requirements. One way of categorizing them is described as the
FURPS+

model [GRA92], using the acro
nym FURPS to describe the major categories of requirements
with subcategories as shown below.



F
unctionality



U
sability



R
eliability



P
erformance




S
upportability

The "+" in FURPS+ reminds you to include such requirements as:



Design constraints



Implementation requirements



Interface requirements




Physical requirements
.

Functional requirements

specify actions that a system must be able to perform, without taking
physical constraints into consideration. These are often best des
cribed in a
use
-
case model

and in
use cases
. Functional requirements thus specify the input and output behavior of a system.

Requirements that are not functional, such as the ones listed below, are sometimes called
non
-
functional requirements
. Many requirements are non
-
functional, and describe only attributes of the
system or attributes of the system environment. Although some o
f these may be captured in
use

42

cases
, those that cannot may be specified in
Supplementary Specifications
. Nonfunctional
requi
rements are those that address issues such as those described below.

A complete definition of the software requirements,
use cases
, and
Supplementary Specifications

may be packaged together to define a
Software Requirements Specification (SRS)

for a particular
"feature" or other subsystem grouping.

Functionality

F
unctional requirements may include:



feature sets



capabilities



security

Usability

Usability requirements may include such subcategories as:



human factors



aesthetics



consistency in the user interface



online and context
-
sensitive help



wizards and agents



user documentation



training materials

Reliability

Reliability requirements to be considered are:



frequency and severity of failure



recoverability



predictability



accuracy



mean time between failure (MTBF)

Performance


43

A performance requirement imposes cond
itions on functional requirements. For example, for a
given action, it may specify performance parameters for:



speed



efficiency



availability



accuracy



throughput



response time



recovery time



resource usage

Supportability

Supportability requirements may include:



testability



extensibility



adaptability



maintainability



compatibility



configurability



serviceability



installability



localizability (internationalization)

FURPS

FURPS

is an acronym representing a model for classifyin
g software quality attributes (
functional

&
non
-
func
tional

requirements
):



F
unctionality

-

Feature set, Capabilities, Generality, Security



U
sability

-

Human factors, Aesthetics, Consistency, Documentation



R
eliability

-

Frequency/severity of failure, Recoverability, Predictability, Accuracy, Mean
time to failure



P
erformance

-

Speed, Effici
ency, Resource consumption, Throughput, Response time


44



S
upportability

-

Testability, Extensibility, Adaptability, Maintainability, Compatibility,
Configurability, Serviceability
, Installability, Localizability,
Portability

There are many definitions of these
Software Quality Attributes

but a common
one is the
FURPS+ model

which was developed by Robert Grady at HewlettPackard.


Under the
FURPS
, the following characteristics are identified:
-



Functionality


The F in the FURPS+ acronym represents all the system
-
wide functional requirements
that we would expect to see described.

These usually represent the main product features that are familiar within the business
domain of the solution being developed.

For
example, order processing is very natural for someone to describe if you are
developing an order processing system.

The functional requirements can also be very technically oriented.

Functional requirements that you may consider to be also architecturall
y significant
system
-
wide functional requirements may include auditing, licensing, localization,
mail, online help, printing, reporting, security, system management, or workflow.

Each of these may represent functionality of the system being developed and
they are
each a system
-
wide functional requirement.


Usability


Usability includes looking at, capturing, and stating requirements based around user
interface issues, things such as accessibility, interface aesthetics, and consistency
within the user inte
rface.


Reliability

Reliability includes aspects such as availability, accuracy, and recoverability, for
example, computations, or recoverability of the system from shut
-
down failure.


Performance


Performance involves things such as throughput of infor
mation through the system,
system response time (which also relates to usability), recovery time, and startup time.


45


Supportability


Finally, we tend to include a section called Supportability, where we specify a number
of other requirements such as testa
bility, adaptability, maintainability, compatibility,
configurability, installability, scalability, localizability, and so on.


The FURPS
-
categories are of two different types:


Functional (F) and Non
-
functional (FURPS).


These categories can be used as

both product requirements as well as in the assessment of product
quality.


Functional (what behaviors it does) and non
-
functional(how it does them)

Functional requirements describe system behaviors

1. Priority: rank order the features wanted in importanc
e

2. Criticality: how essential is each requirement to the overall system?

3. Risks: when might a requirement not be satisfied? What can be done to reduce this risk?


Non
-
functional requirements describe other desired attributes of overall system


1.
Product cost (how do measure cost?)

2. Performance (efficiency, response time? Startup time?)

3. Portability (target platforms?), binary or byte
-

code compatibility?

4. Availability (how much down time is acceptable?)


46

5. Security (can it prevent intrusion?
)

6. Safety (can it avoid damage to people or environment?)

7. Maintainability (in OO context: extensibility, reusability)



FURPS classification










47




FURPS+


Functionality

_ All functional requirements

_ Usually represent main product features.

E.g. Order Processing requirements.

_ Can also be architecturally significant.

Auditing, Licensing, Localization, Mail, Online help, Printing,

Reporting,

Security,
System management, Work
fl
ow.


Usability

User interface issues such as accessibility,
aesthetics and consistency.

Reliability

Availability, accuracy, recoverability.

Performance

Throughput, response time, recovery time, start
-
up time.


Supportability

Testability, adaptability, maintainability, compatibility, configurability ,Installability,

scalability and localizability.


+

Design requirement


48

A design requirement, often called a
design constraint
, specifies or constrains the design of
a system.

E.g. a relational database is required.

Implementation requirement

An implementation requirement specifies or constrains the coding or construction of a
system. Examples are:



required standards



implementation languages



policies for database integrity



resource limits



operation environments

E.g. required standards, platfor
m or implementation language.


Interface requirement

An interface requirement specifies:



an external item with which a system must interact



constraints on formats, timings, or other factors used by such an interaction


Physical requirement

A physical
constraint imposed on the hardware

used to house the system; for example,
shape,

size and weight.

This type of requirement can be used to represent hardware requirements, such as the physical
network configurations required.






49


G
il
b

A
p
p
r
o
a
ch

Tom Gilb

proposed an approach to defining
quality

described as "design by measurable
objectives"

Design by Measurable Objectives

Break down high
-
level abstract concepts to more concret
e ideas that can be measured.


For Example:



Reliability

o

Number of errors in system over a period

o

System up
-
time


This approach is tailored to the product being developed, so is more focussed and relevant to
product needs.

However, because each product is different, and will have different criteria, it's very difficult
to compare the quality of different products.










50

Quality Prompts



Quality prompts ask you to argue in support of the qualities of a person, place or
thing. Qualities means positive aspects
or characteristics, for example: When answering a quality prompt, use G+3TiC=C and the six steps to demonstrate

OPDUL=C in your essay.




Quality prompts
t What are the qualities of a good university? Develop

your po
sition using illustrations
and reasons.






UN
I
T

I
I
I

Q
U
A
L
I
T
Y

M
A
N
A
G
E
M
E
N
T

S
Y
S
T
E
M

E
L
E
M
E
N
T
S

O
F

A

Q
UA
LI
T
Y

E
N
G
I
N
EE
RI
N
G

P
R
O
G
R
A
M


Q
U
A
LI
T
Y

C
O
N
T
R
O
L

Quality control

Quality

control

is a process employed to ensure a certain level of
quality

in a product or
service. It may include whatever actions a business deems necessary to provide for the
control

and verification of certain characteristics of a product or service. The basic goal of
quality

control

is to ensure that the products, services,

or processes provided meet specific
requirements and are dependable, satisfactory, and fiscally sound.

Essentially,
quality

control

involves the examination of a product, service, or process for
certain minimum levels of
quality
. The goal of a
quality

con
trol

team is to identify products
or services that do not meet a company’s specified standards of
quality
. If a problem is
identified, the job of a
quality

control

team or professional may involve stopping production

51

temporarily. Depending on the particula
r service or product, as well as the type of problem
identified, production or implementation may not cease entirely.

Quality control (QC) is a procedure or set of procedures intended to ensure that a
manufactured product or performed service adheres to a
defined set of quality criteria or
meets the requirements of the client or customer. QC is similar to, but not identical with,
quality assurance

(QA). QA is
defined as a procedure or set of procedures intended to ensure
that a product or service under development (before work is complete, as opposed to
afterwards) meets specified requirements. QA is sometimes expressed together with QC as a
single expression,
quality assurance and control (QA/QC).

In order to implement an effective QC program, an enterprise must first decide which specific
standards the product or service must meet. Then the extent of QC actions must be
determined (for example, the percentage o
f units to be tested from each lot). Next, real
-
world
data must be collected (for example, the percentage of units that fail) and the results reported
to management personnel. After this, corrective action must be decided upon and taken (for
example, defec
tive units must be repaired or rejected and poor service repeated at no charge
until the customer is satisfied). If too many unit failures or instances of poor service occur, a
plan must be devised to improve the production or service process and then that

plan must be
put into action. Finally, the QC process must be ongoing to ensure that remedial efforts, if
required, have produced satisfactory results and to immediately detect recurrences or new
instances of trouble.

Quality control

is a process by which

entities review the quality of all factors involved in
production. This approach places an emphasis on three aspects

1.

Elements such as controls, job management, defined and well managed processes

2.

performance and integrity criteria, and identification of re
cords

3.

Competence, such as knowledge, skills, experience, and qualifications

4.

Soft elements, such as personnel
integrity
,
confidence
,
organizational culture
,
motivation
,
team spirit
, and quality relationsh
ips.

The quality of the outputs is at risk if any of these three aspects is deficient in any way.


52

Quality control emphasizes testing of products to uncover defects, and reporting to
management who make the decision to allow or deny the release, whereas
quality assurance

attempts to improve and stabilize production, and associated processes, to avoid, or at least
minimize, issues that led to the defects in the first place. For contract work, part
icularly work
awarded by government agencies, quality control issues are among the top reasons for not
renewing a contract.

Quality control in project management

In
project management
, quality

control requires the project manager and the project team to
inspect the accomplished work to ensure it's alignment with the project scope
.

In practice,
projects typically have a dedicated quality control team which focuses on this area.

QUALITY
ASSURANCE

Quality assurance
, or
QA

for short, is the systematic monitoring and evaluation of the
various aspects of a project, service or facility to maximize the probability that minimum
standards of quality are being attained by the production process. Q
A cannot absolutely
guarantee the production of
quality

products.

Two principles included in QA are: "Fit for purpose"
-

the product should be suitable for the
intended purpose; and "Right first time"
-

mistakes should be eliminated. QA includes
regulation

of the
quality

of raw materials, assemblies, products and components, services
related to production, and management, production and inspection processes.

Quality

is determined by the product users, clients or customers, not by society in general. It
is not the same as 'expensive' or 'high quality'. Low priced products can be considered as
having high quality if the product users determine them as such.

Steps for a
typical quality assurance process

There are many forms of QA processes, of varying scope and depth. The application of a
particular process is often customized to the production process.

A typical process may include:


53



test of previous articles



plan to impr
ove



design to include improvements and requirements



manufacture with improvements



review new item and improvements



test of the new item

Failure testing

Valuable processes to perform on a whole
consumer

product is failure testing or
stress
testing
. In mechanical terms this is the operation of a product until it fails, often under
stresses such as increasing
vibration
,
temperature
, and
humidity
. This exposes many
unanticipated
weaknesses

in a product, and the data are used to drive engineering and
manufacturing
process improvements
. Often quite simple changes can dramatically improve
product service, such as changing to
mold
-
resistant
paint

or adding
lock
-
washer

placement to
the
training

for new assembly personnel.

Statistical control

Many organizations use
statistical process control

to bring the
organization

to
Six Sigma

levels
of quality,
[

in other words, so that the likelihood of an unexpected failure is confined to
six
standard deviations

on the
normal distribution
. This probability is less than four
one
-
millionths
. Items controlled often include
clerical tasks

such as order
-
entry as well as
conventional manufacturing tasks.

Traditional statistical process controls in manufacturing operations usually proceed by
randomly sampling and testing a fraction of the output. Variances in critical to
lerances are
continuously tracked and where necessary corrected before bad parts are produced.

Total quality management

The quality of products is dependent upon that of the participating constituents, some of
which are sustainable and effectively controll
ed while others are not. The process(es) which
are managed with QA pertain to
Total Quality Management
.


54

If the specification does not reflect the true quali
ty requirements, the product's quality cannot
be guaranteed. For instance, the parameters for a pressure vessel should cover not only the
material and
dimensions

but operating, environmental,
safety
,
reliability

and
maintainability

requirements.

QA is not limited to the manufacturing, and can be applied to any business or non
-
business
activity:



Design work



Administrative services



Consulting



Banking



Insurance



Computer software development



Retailing



Transportation



Education



Translation


It comprises a quality improvement process, which is generic in the sense it can be applied to
any of these activities and it establishes a
behavior pattern
, which supports the achievement
of quality.This in turn is supported by quality management practices which can include a
number of
business systems

and which are usually specific to the activities of the
business
unit

concerned.In manufacturing and
construction

activities, these business practices can be
equated to the models for quality assurance defined by the International Standards contained
in the
ISO 9000

s
eries and the specified
Specifications

for quality systems.In the system of
Company Quality, the work being carried out was shop floor inspection which did not reveal
the major q
uality problems. This led to quality assurance or total quality control, which has
come into being recently

Quality management

can be considered to have four main components: quality planning,
qu
ality control
,
quality assurance

and quality improvement. Quality management is focused
not only on product/
service quality
, but als
o the means to achieve it. Quality management

55

therefore uses quality assurance and control of processes as well as products to achieve more
consistent quality.

VARIABLES THAT AFFECT THE QUALITY OF RESULTS

The educational background and




Th
e
educational
background and

training of the laboratory personnel



The condition of the specimens



The controls used in the test runs



Reagents



Equipment



The interpretation of the results



The transcription of results



The reporting of results



What Is the Difference Between Quality Assurance and Quality Control?

The Prime Focus of


Quality Management


Quality Assurance

Achieving results that satisfy the requirements for
quality.

Demonstrating that the requirements for
quality have been (and can be) achieved.

Motivated by stakeholders internal to the
organization, especially the organization’s
management

Motivated by stakeholders, especially
customers, external to the organizati
on

Goal is to satisfy all stakeholders

Goal is to satisfy all customers.

Effective, efficient, and continually improving,
overall quality
-
related performance is the
Confidence in the organization’s products is
the intended result


56

intended result.

Scope covers all activities that affect the total
quality
-
related business results of the organization

Scope of demonstration coves activities that
directly affect quality
-
related process and
product results



HI
S
T
O
RI
C
A
L

PE
R
S
PE
C
T
I
VE

E
L
E
M
E
N
T
S

O
F

Q
M
S



T
IM
E
M
ANAGE
M
E
N
T


Time management

is the act or process of exercising conscious control over the amount of
time spent on specific activities, especially to increase efficiency or productivity. Time
management may be aided by a range of skills, tools, and tec
hniques used to
manage

time
when accomplishing specific tasks, projects and goals. This set encompasses a wide scope of
activities, and these include
planning
,
allocating
,
setting goals
, delegation, analysis of time
spent,
monitoring
, organizing, scheduling, and prioritizing. Initially, time management
referred to just business or work activities, but eventually the term broadened to include
personal activities as well. A

time management system is a designed combination of
processes, tools, techniques, and methods. Usually time management is a necessity in any
project development as it determines the project completion time and scope.

Time management and related concepts

T
ime management has been considered as subsets of different concepts such as:



Project management
.

Time Management can be considered as a project management
subset and is more commonly known as
project planning

and project scheduling.

57

Time Management has also been identified as one of the core functions identified in
project management.



Attention management
:

Attention Management relates to the management of
cognitive

resources, and in particular the time th
at humans allocate their mind (and
organizations the minds of their employees) to conduct some activities.

Personal knowledge management
(
Personal time management) .Time management
strategies are often associated with the recommendation to set personal goals. These goals are
recorded and may be broken down into a
project
, an
action plan
, or a simple task list. For
individual tasks or for goals, an importance rating may be established, deadlines may be set,
and priorities assigned. This process results in a plan with a task li
st or a schedule or calendar
of activities. Authors may recommend a daily, weekly, monthly or other planning periods
associated with different scope of planning or review. This is done in various ways, as
follows.

Time management also covers how to elimina
te tasks that don't provide the individual or
organization value.





One goal is to help yourself become aware of how you use your time


as one resource in organizing, prioritizing, and succeeding in your
studie
s

in the context of competing activities of friends, work, family, etc.

Strategies on using time:

These applications of time management have proven to be effective as good study habits.

As we go through each strategy, jot down an idea of wha
t each will look like for you:



Blocks of study time and breaks

As your school term begins and your course schedule is set, develop and plan for,
blocks of study time in a typical week.


Blocks ideally are around 50 minutes, but
perhaps you become restless after only 30 minutes? Some difficult material may
require more

frequent breaks. Shorten your study blocks if necessary

but don’t
forget to return to the task at hand!


What you do during your break should give you
an opportunity to have a snack, relax, or otherwise refresh or re
-
energize yourself. For

58

example, place
blocks of time when you are most productive:


are you a morning
person or a night owl?





Jot down one best time block you can study.


How long is it?


What makes for
a good break for you?


Can you control the activity and return to your studies?


Dedicated
study spaces

Determine a place free from distraction (no cell phone or text messaging!) where you can
maximize your concentration and be free of the distractions that friends or hobbies can
bring!


You should also have a back
-
up space that you can escape t
o, like the
library,


departmental study center, even a coffee shop where you can be anonymous.


A
change of venue may also bring extra resources.





What is the best study space you can think of?


What is another?


Weekly reviews

Weekly reviews and updates are also an important strategy.


Each week, like a Sunday night,
review your assignments, your notes, your calendar. Be mindful that as deadlines and exams
approach, your weekly routine must adapt to them!





What is the best time

in a week you can review?


Prioritize your assignments

When studying, get in the habit of beginning with the most difficult subject or task.


You’ll
be fresh, and have more energy to take them on when you are at your best.


For more difficult
courses of st
udy, try to be flexible:


for example, build in “reaction time” when you can get
feedback on assignments before they are due.



What subject has always caused you problems?



Achieve “stage one”
--
get something done!

The Chinese adage of the longest journey s
tarting with a single step has a couple of
meanings:


First, you launch the project!


Second, by starting, you may realize that
there are some things you have not planned for in your process. Details of an
assignment are not always evident until you begin
the assignment.


Another adage is
that “perfection is the enemy of good”, especially when it prevents you from starting!
Given that you build in review, roughly draft your idea and get


going!


You will have
time to edit and develop later.



What is a first

step you can identify for an assignment to get yourself started?


Postpone unnecessary activities until the work is done!

Postpone tasks or routines that can be put off until your school work is finished!




59

This can be the most difficult challenge of time
management.


As learners we always meet
unexpected opportunities that look appealing, then result in poor performance on a test, on a
paper, or in preparation for a task. Distracting activities will be more enjoyable later without
the pressure of the test,

assignment, etc. hanging over your head.


Think in terms of pride of
accomplishment. Instead of saying “no” learn to say “later”.



What is one distraction that causes you to stop studying?


Identify resources to help you

Are there tutors?


An “expert frie
nd”? Have you tried a keyword search on the Internet to get
better explanations?


Are there specialists in the library that can point you to
resources?


What about professionals and professional organizations.


Using outside
resources can save you time and

energy, and solve problems.



Write down three examples for that difficult subject above?



Be as specific as possible.


Use your free time wisely

Think of times when you can study "bits" as when walking, riding the bus, etc.


Perhaps
you’ve got music t
o listen to for your course in music appreciation, or drills in language
learning?


If you are walking or biking to school, when best to listen? Perhaps you are in a
line waiting?


Perfect for routine tasks like flash cards, or if you can concentrate, to r
ead or
review a chapter.


The bottom line is to put your time to good use.



What is one example of applying free time to your studies?

Review notes and readings just before class

This may prompt a question or two about something you don’t quite understand, to ask about
in class, or after.


It also demonstrates to your


teacher that you are interested and have
prepared.



How would you make time to review?

Is there free time you can
use?



Review lecture notes just after class

Then review lecture material immediately after class.



The first 24 hours are critical.


Forgetting is greatest within 24 hours without review!


60



How would you do this?

Is there free time you can use?

Effective
aids:



This simple program will help you identify a few items, the reason for doing them, a
timeline for getting them done, and then printing this simple list and posting it for
reminders.




Daily/weekly planner

Write down appointments, classes, and meetings

on a chronological log book or chart.

If you are more visual, sketch out your schedule

First thing in the morning, check what's ahead for the day

always go to sleep knowing you're prepared for tomorrow



Long term planner

Use a monthly chart so that you c
an plan ahead.

Long term planners will also serve as a reminder to constructively plan time for
yourself


Time Management Tips

1) Realize that time management is a myth.

No matter how organized we are, there are always only 24 hours in a day. Time doesn't

change. All we can actually manage is ourselves and what we do with the time that we have.

2) Find out where you're wasting time.

Many of us are prey to time
-
wasters that steal time we could be using much more
productively. What are your time
-
bandits? Do
you spend too much time 'Net surfing, reading
email, or making personal calls?
Tracking Daily Activities

explains how to track your
activities so you can form a accurate picture of w
hat you actually do, the first step to effective
time management.


61

3) Create time management goals.