CHAPTER 3

Manaj Kualitas SISoftware Quality Factors

LIKMI/RA

OS /2

The need for a comprehensive

definition of requirements
Terdapat suatu kebutuhan terhadap
definisi persyaratan kualitas yang
mencakup banyak hal, yang meliputi
seluruh atribut software dan aspekaspeknya - seperti aspek usability,
aspek reusability, aspek pemeliharaan,
dll dalam tujuannya untuk
meyakinkan kepuasan penuh dari para
pengguna.
RA /3

The need for a comprehensive

definition of requirements
There is a need for a
comprehensive definition of
requirements that will cover all
attributes of software and aspects
of the usability aspects, reusability
aspects, maintainability aspects,
and so forth in order to assure the
full satifaction of the users.
RA /4

Classification of software
requirements into software quality
factors
The classic model of software
quality factors suggest by :
McCall (consist of 11 factors, 1977)
Deutsch and Willis (consist of 12 to 15
factors, 1988)
Evans and Marciniak (1987)

RA /5

McCalls Factor Model

Classifies all software requirement into
11 software quality factors.
The 11 factors are grouped into three
categories :
1. Product operation factors : Correctness,
Reliability, Efficiency, Integrity, Usability.
2. Product revision factors : Maintability,
Flexibility, Testability.
3. Product transition factors : Portability,
Reusability, Interoperability.

McCalls Factor Model

Product Operation Software Quality

Factors - Correctness
Correctness requirements are defined in a list
of the software systems required outputs.
Output specifications are usually
multidimensional; some common dimensions
include :
The output mission
The required accuracy of output
The completeness of the output information
The up-to-dateness of the information
The availability of the information
The standards for coding and documenting the
software system.
RA /8

Product Operation Software

Quality Factors - Reliability
Reliability requirements deal with failures to provide
service.
Determine the maximum allowed software system
failures rate, and can refer to the entire system or
to one or more of its separate functions.
Examples :
1. The failures frequency of a heart-monitoring unit that will
operate in a hospitals intensive care ward is required to be
less than one in 20 years. Its heart attack detection
function is required to have a faliure rate of less than one
per million cases.
2. One requirement of the new software system to be
installed in the main branch of Independence Bank, which
operates 120 branches, is that it will not fail, on average,
more than 10 minutes per month during the banks office
hours.
RA//9

Product Operation Software Quality

Factors - Efficiency
Efficiency requirements deal with the
hardware resources needed to perform
all the functions of the software system
in conformance to all other requirements.
Examples :
1. A chain stores is considering two alternative
bids for a software system.
2. An outdoor meteorological unit, equipped
with a 1000 milli-ampere hour cell, should be
capable of supplying the power requirements
of the unit for at least 30 days.
RA /10

Product Operation Software Quality

Factors - Integrity
Integrity requirements deal with the
software system security, that is
requirements to present access to
anauthorized person, to distinguish
between the majority of personnel
allowed to see the information (read
permit) and alimited group who will
be allowedf to add and change data
(write permit), and so forth.
RA /11

Product Operation Software Quality

Factors - Usability

Usability requirements deal with the scope of

staff resources needed to train a new
employee and to operate the software system.
Example :
The software usability requirements document
for the new help desk system initiated by a
home appliance service company lists the
following specifications :
a.
b.

A staff member should be able to handle at least 60

service calls a day
Training a new employee will take no more than two
days, immediately at the end of which the trainee
will be able to handle 45 service calls a day.
OS /12

Product Revision software Quality

Factors
According to the McCsll model of software
quality factors, three quality factors
comprise the product revision category.
These factors deal with those
requirements that affest the complete
range of software maintenance activities :
Corrective maintenance
Adaptive maintenance
Perfective maintenance
RA/13

Product Revision software Quality

Factors - Maintability
Maintability requirements determine the efforts
that will be needed by users and maintenance
personnel to identify the reasons for software
failures, to correct the failures, and to verify the
success of the corrections.
This factors requirements determine refer to the
modular structure of software, the internal
program documentation, and the programmers
manual, among other items.
Example typical maintability requirements :
a. The size of a software module will not exceed
30 statements.
b. The programming will adhere to the company
coding standards and guidelines.
RA /14

Product Revision software Quality

Factors - Flexibility
The capabilities and efforts required to
support adaptive maintenance activities
are covered by the flexibility requirements.
These include the resources (i.e in mandays) required to adapt a software package
to a variety of customers of the same
trade, of various extents of activities, of
differents ranges of products, and so on.
This factors requirements also support
perfective maintenance activities.
RA/15

Product Revision software Quality

Factors - Testability
Testability requirements deal with the
testing of an information system as
well as with its operation.
Testability requirements for the ease of
testing are related to special features
in the programs that help the tester,
for instance by providing predefined
intermdiate results and log files.
OS /16

Product Transition software

Quality Factors - Portability
Portability requirements tend to
the adaptation of software system
to other environtments consisting
of different hardware, different
operating systems, and so forth.

RA /17

Product Transition software

Quality Factors - Reusability
Reusability requirements deal with
the use of software modules
originally designed for one project
currently being developed.

RA /18

Product Transition software

Quality Factors - Interoperability
Interoperability requirements focus
on creating interfaces with other
software systems or with other
equipment firmware.
Interoperability requirements can
specify the name(s) of the software
or firmware for which interface is
required.
RA /19

Alternative Models of Software

Quality Factors
Formal comparison of the
alternative models
Comparison of the factors modelscontent analysis
Structure of the alternative factor
models

OS /20

Who is interested in the

definition of quality
requirements?

Some quality factors not included in the

typical clients requirements document
may, in many case, interest the developer.
The following lists of quality factors usualyy
interest the developer whereas they may
raise very little interest on the part of the
client :
Portability
Reusability
Verifiability
RA/21

Requirements Documents
A project will be carried out to
according to two requirements
documents :
The clients requirements
document
The developers additional
requirements document
RA /22

Software Compliance with

Quality Factors
The softwares product compliance to
the requirements belonging to the
various quality factors is measured by
software quality metrics, measures that
quantify the degree of compliance.
In order to allow for valid measurements
of compliance, sub-factors have been
defined for those quality factors that
represent a wide range of attributes and
aspects of software use.
RA /23

Factors and sub-factors

RA /24

Factors and sub-factors (cont.)

RA /25

Factors and sub-factors (cont.)

OS /26

Summary
1. The need for a comprehensive
requirements documents and their
contents.
2. The structure (categories and factors)
of McCalls classic factor model.
3. The additional factors suggested by
alternatives factor models.
4. Thode interested in defining software
quality requirements.
RA /27

Tugas kelompok di kelas

Sebutkan faktor kualitas apa yang

ditunjukkan pernyataan di bawah ini
kemudian jelaskan dengan singkat
alasannya.

RA /28

Tugas

1. Perangkat lunak dari peralatan produksi yang

diperlukan untuk memproses hasil (output)
sesuai dengan struktur data standar yang
kemudian dapat berfungsi sebagai masukan
untuk sejumlah sistem informasi.
2. Perangkat lunak rumah sakit ini harus
dikembangkan untuk dapat diadaptasi
kemudian untuk berbagai rumah sakit swasta
lainnya.
3. Pelatihan teknisi laboratorium, yang
membutuhkan perangkat lunak tidak lebih dari
tiga hari untuk dapat dengan mahir
menggunakan perangkat lunak.
RA /29

Tugas

4. Perangkat lunak yang dikembangkan untuk sistem

operasi Linux harus kompatibel untuk aplikasi dalam
lingkungan Windows NT
5.Peluang sistem perangkat lunak terjadi kegagalan
saat jam sibuk (09:00-16:00) berada di bawah 0,5%.
6.Super-lab software system memungkinkan untuk
transfer hasil lab secara langsung ke file pasien rumah
sakit pada paket software MD-FILE
7.Super-lab subsystem harus sesuai dengan tagihan
pasien di sistem poliklinik yang digunakan.
8.Software system harus beroperasi pada 12
workstations, 8 mesin pengujian otomatis dan 1 server
utama termasuk communication server untuk 25 jalur
komunikasi.

RA /30

The Components of the

software quality assurance
system-overview

Chapter 4

09/21/1515:23

3
1

The SQA System an SQA

architecture
An SQA system always combine a wide
range of SQA components, all of which
are employed to challenge the multitude
of sources of software errors and to
achieve an acceptable level of software
quality.
The task of SQA is unique in the area of
quality assurance due to the special
characteristics of software (Chapter 1)
The environment in which software
development and maintenance is
undertaken directly influences the SQA
components.
09/21/15 15:23R
A/

The software quality shrine the SQA

architecture

SQA system components can be

classified into six classes:

1. Pre-project components-1
1. Contract review
Definisi :

Memeriksa Draft Proposal Proyek

Draft Kontrak

Aktifitas :

Klarifikasi kebutuhan pelanggan

Review jadwal proyek dan perkiraan
kebutuhan sumber daya
Evaluasi kemampuan staf profesional untuk
melaksanakan proyek
Evaluasi kemampuan pelanggan untuk
memenuhi kewajibannya
Evaluasi resiko-resiko dari pengembangan

2. Development and quality plans.

09/21/15 15:233
5

1. Pre-project components-2
2. Development and quality plans.
The main issues treated in the project development plan
are
Schedules
Required manpower and hardware resources
Risk evaluations
Organizational issues: team members, subcontractors and
partnerships
Project methodology, development tools, etc.
Software reuse plans.

The main issues treated in the projects quality plan are:

Quality goals, expressed in the appropriate measurable terms
Criteria for starting and ending each project stage
Lists of reviews, tests, and other scheduled verification and
validation activities.
09/21/15 15:233
6

Development and quality plans.

The main issues treated in the project
development plan are:
Schedules
Required manpower and hardware resources
Risk evaluations
Organizational issues: team members,
subcontractors and partnerships
Project methodology, development tools, etc.
Software reuse plans.

09/21/15 15:233
7

Development and quality plans.

The main issues treated in the projects
quality plan are:
Quality goals, expressed in the
appropriate measurable terms
Criteria for starting and ending each
project stage
Lists of reviews, tests, and other
scheduled verification and validation
activities.
09/21/15 15:233
8

2. Software project life cycle

components
The project life cycle is composed of two stages:
the development life cycle
stage and the operationmaintenance stage.
The main components are:
1.Reviews
2.Expert opinions
3.Software testing
4.Software maintenance
5.Assurance of the quality of the subcontractors
work and the customersupplied parts.
09/21/15 15:233
9

2.1 Reviews
The design phase of development
process produces a variety of documents.
The printed products include :
design reports,
software test documents,
software installation,
software manual,etc.

Reviews can be categorized as :

Formal design Reviews (DRs)
Peer Reviews
09/21/15 15:23R
A/

Formal design Reviews (DRs)

A significant portion of these document
requires formal professional approval of
their quality as stipulated in
development contract and demanded
by procedures applied by the software
developer.
The DR report include a list of required
corrections (termed actions items).
09/21/15 15:23R
A/

Peer Reviews
Peer reviews (inspections and walkthroughs) are
directed at reviewing short documents, chapters or
parts of a report, a coded printout of a software
module, and the like.
Inspections and walkthroughs can take several
forms and use many methods.
The reviewers are all peers, not superiors, who
provide professional assistance to colleagues.
The main objective of inspections and
walkthroughs is to detect as many design and
programming faults as possible.
09/21/15 15:23R
A/

2.2 Expert Opinions

Expert Opinions support quality assessment efforts by
introducing additional external capabilities into the
organizations in-house development process.
Turning to outside experts may be particularly useful in the
following situations:
Insufficient in-hose professional capabilities in a given area
In small organizations in many cases it is difficult to find
enough suitable candidates to participate in the design
review teams.
In small organizations or in situations characterized by
extreme work pressures, an outside experts opinion can
relace an inspection.
Temporary inaccessibility of in-house professional
In cases of major disagreement among the organizations
senior professional, an outside expert may support a
decision.

09/21/15 15:23R
A/

2.3 Software Testing

Software tests are formal SQA components
that are targeted toward review of the actual
running of the software.
The test are based on a prepared list of test
cases that represent a variety of expected
scenarios.
The test report will include a detailed list of
the faults detected and recommendation
about performance of partial or complete
recurrent test following a subsequent round of
corrections based on the test findings.
09/21/15 15:23R
A/

2.4.Software Maintenance
Components
Software maintenance services vary
in range and are provided for
extensive periods, often several years.
These services falll into the following
categories :
Corrective maintenance
Adaptive maintenance
Functionally improvement maintenance
09/21/15 15:23R
A/

2.5 Assurance of the Quality of the

External Participants work
Most of SQA controls applied to external
participants are defined in the contracts
signed between the relevants parties.
Special software assurance efforts are
required to establish effective controls
over the external participants work.
Special SQA efforts are needed to assure
the quality of the hardware, software,
staff and training supplied by customer.
09/21/15 15:23R
A/

3. Infrastructure components for

error prevention and improvement

The goals of SQA infrastructure are

the prevention of software faults or,
At least, the lowering of software fault rates,
together with the improvement of productivity.

This class of SQA components includes:

Procedures and work instructions
Templates and checklists
Staff training, retraining, and certification
Preventive and corrective actions
Configuration management
Documentation control.
09/21/15 15:234
7

4.Management SQA components

Control components include:
Project progress control (including
maintenance contract control)
Software quality metrics
Software quality costs.

09/21/15 15:234
8

5. SQA standards, system

certification, and assessment
components

the main objectives of this class of

components are:
1.Utilization of international professional
knowledge.
2.Improvement of coordination with
other organizations quality systems.
3.Objective professional evaluation and
measurement of the achievements of
the organizations quality systems.
09/21/15 15:234
9

6. Organizing for SQA the human

components
This base includes
the organizations management,
software testing personnel and
SQA units in addition to
professionals and other practitioners
interested in software quality (SQA
trustees, SQA committee members
and SQA forum members).
09/21/15 15:235
0

6. Organizing for SQA the human

components
The main objectives of the SQA
organizational base are as follows:
To develop and support implementation
of SQA components.
To detect deviations from SQA
procedures and methodology.
To suggest improvements to SQA
components.
09/21/15 15:235
1

Questions ?

Thank you

TUGAS 2

RA /53