Software Engineering:

A Practitioners Approach, 7/e

by Roger S. Pressman

Chapter 23, 24, 25, 26, 27

Pengampu: Wahyuni
1

Chapter 23
Product

Metrics

Slide Set to accompany

Software Engineering: A Practitioners Approach, 7/e

by Roger S. Pressman
Slides copyright 1996, 2001, 2005, 2009 by Roger S. Pressman

What is Product Metrics ?

Metrik proses dan produk perangkat lunak adalah sarana

untuk mengukur (kuantitatif) yang memungkinkan praktisi
perangkat lunak untuk mendapatkan informasi tentang
efektivitas dari proses dan produk perangkat lunak yang
dikerjakan dengan menggunakan proses sebagai kerangka
kerjanya.
Dilakukan dengan mengumpulkan kualitas dan produktivitas
data.
Data tersebut kemudian dianalisis, dibandingkan terhadap
rata-rata masa lalu, dan dinilai untuk menentukan apakah
perbaikan kualitas dan produktivitas telah terjadi.
Metrik ini juga digunakan untuk menentukan area
permasalahan sehingga penyelesaian dapat dikembangkan
dan proses perangkat lunak dapat ditingkatkan.
3

Who does it?

Software metrics are
analyzed and assessed
by software managers.
Measures are often
collected by software
engineers.

Metrik perangkat lunak

dianalisis dan dinilai oleh
manajer perangkat lunak.
Perlengkapan
pengukuran dilakukan
oleh para pengembang
perangkat lunak.

Why is it important?
If you dont measure,
judgement can be based only
on subjective evaluation. With
measurement, trends (either
good or bad) can be spotted,
better estimates can be made,
and true improvement can be
accomplished over time.

Jika tidak diukur, maka

penilaian hanya akan bersifat
evaluasi subyektif. Dengan
metriks, pengukuran baik atau
buruk dapat dilihat, perkiraan
dapat dibuat lebih baik, dan
perbaikan yang sebenarnya
dapat dicapai dari waktu ke
waktu.

What are the steps?

Langkah dimulai dengan mendefinisikan pengukur proses,

proyek, dan produk yang dapat dengan mudah
dilaksanakan. Langkah-langkah ini sering dinormalisasi
dengan menggunakan metrik ukuran atau fungsi-oriented.
Hasilnya dianalisis dan dibandingkan dengan data masa
lalu untuk proyek-proyek serupa. Tren dinilai dan kemudian
ditarik kesimpulan.

What is the work product?

Produknya adalah seperangkat metrik

perangkat lunak yang memberikan
wawasan terhadap proses dan
pemahaman terhadap proyek.

McCalls Triangle of Quality

Maintainability
Flexibility
Testability
PRODUCT REVISION

Portability
Reusability
Interoperability
PRODUCT TRANSITION

PRODUCT OPERATION
Correctness
Usability
Efficiency
Integrity
Reliability

An Overview of Factors That Affect Quality

McCall menyatakan bahwa kerangka kerja:
1.menyediakan

mekanisme bagi manajer proyek untuk

mengidentifikasi kualitas yang dinilai penting (diantaranya adalah
maintainability dan portabilitas.
2.menyediakan sarana untuk secara kuantitatif menilai seberapa
baik proyek mengalami kemajuan dipandang dari derajat
kualitas yang telah ditetapkan.
3.menyediakan sarana interaksi yang memadai antar personil
yang sadar terhadap QA di seluruh upaya pengembangan
perangkat lunak.
4.menyediakan indikator akan munculnya kualitas yang tidak
diinginkan untuk membantu menemukan standar yang lebih baik
yang harus ditegakkan di masa depan.

Komentar tentang usulan McCall

Faktor kualitas versi McCall diusulkan pada awal
1970-an, namun faktor-faktor tersebut masih relevan
hingga saat ini. Diprediksi bahwa sampai abad 21
nanti, perangkat lunak yang dibangun dengan
mengindahkan faktor-faktor tersebut akan memiliki
kualitas tinggi, meskipun berlangsung perubahan
yang dramatis dari sisi teknologi.

10

Faktor Kualitas

Meskipun ada banyak pengukur kualitas perangkat

lunak, namun correctness, maintainability, integrity, and
usability memberikan indikator yang paling berguna
untuk tim proyek.

Correctness. Sebuah program harus beroperasi

dengan benar, kalau tidak, maka program tersebut
tidak memiliki arti bagi pengguna. Ukuran yang paling
umum untuk correctness kesalahan per KLOC
Integrity. Integritas perangkat lunak telah menjadi
semakin penting di era hacker dan firewall. Atribut ini
mengukur kemampuan sebuah sistem untuk
menahan gangguan (baik disengaja atau tidak) untuk
keamanannya.
11

Gangguan dapat terjadi pada ketiga komponen

perangkat lunak: program, data, dan dokumen. Untuk
mengukur integritas, dua atribut tambahan harus
didefinisikan: yaitu threat dan security.

adalah probabilitas (yang dapat diestimasi atau

berasal dari bukti empiris) bahwa gangguan tipe tertentu akan
terjadi dalam waktu tertentu. Security adalah probabilitas
(yang dapat diestimasi atau berasal dari bukti empiris) bahwa
gangguan tipe tertentu akan ditolak. Integritas sistem kemudian
dapat didefinisikan sebagai
Threat

integrity = summation [(1 threat) (1 security)]

dimana threat dan security adalah penjumlahan untuk
seluruh tipe gangguan.

12

Faktor Kualitas (cont)

Maintainability. Maintainability adalah kemudahan untuk

dikoreksinya program jika kesalahan ditemui, diadaptasi
jika terdapat perubahan lingkungannya, atau ditingkatkan
jika pelanggan menginginkan perubahan kebutuhan. Tidak
ada cara untuk mengukur maintenance secara langsung,
karena itu, harus digunkan tindakan tidak langsung.
Metrik yang berorientasi waktu yang sederhana adalah
MTTR, atau waktu rata-rata yang diperlukan untuk
menganalisis permintaan perubahan, merancang
modifikasi yang sesuai, melaksanakan perubahan,
mengujinya, dan mendistribusikan perubahan untuk
semua pengguna. Secara umum, program yang dimaintain akan memiliki MTTR lebih rendah (untuk tipe
perubahanyang sama) dari program yang tidak dimaintain.
13

Usability. Istilah "user-friendliness" selalu menjadi topik utama

dalam berbagai diskusi tentang produk software. it performs are
valuable. Jika sebuah program disebut tidak user-friendly,
diantaranya jika program tersebut sering gagal, padahal fungsi
yang ia lakukan sangat berharga.
Usability adalah suatu usaha untuk mengukur keramahan dan
dapat diukur dalam empat karakteristik: (1) keterampilan dan/atau
kecerdasan yang dibutuhkan untuk dipelajari, (2) waktu yang
diperlukan untuk menjadi cukup efisien dalam penggunaan sistem
, (3) peningkatan yang nyata dalam produktivitas (lebih dari
pendekatan yang sekedar menggantikan sistem) diukur ketika
sistem digunakan oleh seseorang yang cukup efisien dalam
bekerja, dan (4) penilaian subyektif (kadang-kadang diperoleh
melalui kuesioner) dari sikap pengguna terhadap sistem.

14

23.1.1 Measures, Metrics and Indicators

Sebuah measure memberikan indikasi kuantitatif

tentang tingkat, jumlah, dimensi, kapasitas, atau
ukuran dari beberapa atribut dari suatu produk atau
proses.
Sebuah metriks didefinisikan oleh IEEE glossary
sebagai hasil pengukuran yang sifatnya kuantitatif
untuk menentukan tingkat dari sebuah sistem,
komponen, atau proses menurut suatu atribut
tertentu.
Indikator adalah metrik atau kombinasi metrik yang
mewakili gambaran mengenai proses sebuah
perangkat lunak, proses sebuah proyek perangkat
lunak, atau produk dari proses itu sendiri

15

MEASURES, METRICS, AND INDICATORS

(Definisi)

Dalam konteks rekayasa perangkat lunak, sebuah

measure merupakan indikasi kuantitatif tentang
tingkat, jumlah, dimensi, kapasitas, atau besarnya
nilai-nilai atribut produk atau proses tertentu.
Measurement (pengukuran) adalah kegiatan dalam
menentukan measure.
The IEEE Standard Glossary of Software Engineering
Terms [IEE93] mendefinisikan metrik sebagai alat
ukur kuantitatif yang menentukan nilai atribut dari
sebuah sistem, komponen, atau proses tertentu.
Indicator adalah metrik atau kombinasi metrik yang
memberikan wawasan tentang proses perangkat
lunak, proyek perangkat lunak, atau produk itu sendiri
16

MEASURES, METRICS, AND INDICATORS

(Explanation)

Ketika sejumlah kesalahan yang ditemukan dalam

sebuah modul akan diisolasi, maka sejak itulah sebuah
alat ukur ditentukan.
Pengukuran terjadi saat seorang pengukur mulai
mengoperasikan alat ukurnya.
Seorang pengembang perangkat lunak mengumpulkan
dan menentukan alat ukur dan mengembangkan metrik
sehingga indikator akan diketahui.
Indikator memberikan wawasan yang memungkinkan
manajer proyek atau praktisi perangkat lunak
menyesuaikan produk, proyek, atau proses untuk
memperbaiki keadaan.
17

MEASURES, METRICS, AND INDICATORS (Example)

Sebagai contoh,
Empat tim perangkat lunak bekerja pada sebuah proyek
software besar.
Setiap tim harus melakukan review (tinjauan) terhadap desain,
dan diperbolehkan untuk memilih jenis review yang akan
digunakan.
Setelah selesai pemeriksaan, kesalahan yang ditemukan oleh
masing-masing tim (dalam besaran per orang-jam) dilaporkan,
Proyek manajer mencatat bahwa dua tim yang menggunakan
metode pengamatan yang formal menemukan kesalahan 40
persen lebih tinggi dari tim lain (yang tidak menggunakan
metoda formal).

18

Dengan menggunakan asumsi bahwa semua parameter

lainnya sama, maka manajer proyek memperoleh kesimpulan
bahwa metode pengamatan (review) yang formal dapat
menghemat waktu.
Sebagai akibatnya, manajer mungkin akan membuat
keputusan yang mengharuskan semua tim menggunakan
pendekatan yang formal.
Metrik memberikan wawasan kepada manajer, dan wawasan
mengarah pada pembuatan keputusan.

19

23.1.3. Measurement Principles

Tujuan pengukuran harus ditetapkan sebelum pengumpulan data

dimulai;
Setiap teknis metrik harus didefinisikan secara jelas (tidak umbigu);
Metrik harus diderivasi berdasarkan teori yang berlaku dalam
domain aplikasi (misalnya, metrik untuk desain harus memanfaatkan
konsep dan prinsip-prinsip dasar perancangan dan berusaha untuk
memberikan indikasi adanya atribut yang diinginkan);
Metrik harus disesuaikan untuk mengakomodasi produk dan proses
tertentu [Bas84].

20

Measurement Process
Proses untuk mengkur perangkat lunak adalah sbb:
Derivasi pengukur metrik dan perangkat lunak yang tepat
untuk merepresentasikan perangkat lunak yang sedang diperhatikan.
Collection. Mekanisme yang digunakan untuk mengumpulkan data yang
dibutuhkan untuk menderivasi rumus metrik.
Analysis. Perhitungan metrik dan penerapan tools matematika.
Interpretation. Evaluasi hasil metrik dalam upaya untuk mendapatkan
gambaran lengkap tentang kualitas yang direpresentasikannya.
Feedback. Rekomendasi berbasis pada interpretasi terhadap metrik
produk dikirim ke tim perangkat lunak.
Formulation.

21

23.1.4 Goal-Oriented Software Measurement

The Goal/Question/Metric Paradigm

1. menetapkan tujuan pengukuran yang eksplisit, yang khusus berlaku
untuk menilai kegiatan proses atau karakteristik produk tertentu
2. mendefinisikan serangkaian pertanyaan yang harus dijawab dalam
rangka mencapai tujuan pengukuran yang eksplisit tadi, dan
3. mengidentifikasi metrik yang dirumuskan dengan baik, sebagai alat
bantu dalam menjawab pertanyaan-pertanyaan.

Goal definition template

1. Analyze {the name of activity or attribute to be measured}
2. for the purpose of {the overall objective of the analysis}
3. with respect to {the aspect of the activity or attribute that is
considered}
4. from the viewpoint of {the people who have an interest in the
measurement}
5. in the context of {the environment in which the measurement takes
place}.
22

23.1.5 Metrics Attributes

Simple and computable. Relatif mudah untuk dipelajari bagaimana

menderivasikan metrik, dan perhitungannya tidak memakan waktu.
Empirically and intuitively persuasive. Metrik harus memenuhi intuisi
para perekayasa tentang atribut produk yang sedang dinilai
Consistent and objective. Metrik harus selalu memberikan hasil yang
jelas dan tidak ambigu.
Consistent in its use of units and dimensions. Komputasi matematika
metrik harus menggunakan alat ukur yang tidak mengarah ke kombinasi
perhitungan yang terlalu rumit.
Programming language independent. Metrik harus berbasis pada
model analisis, model desain, atau struktur program itu sendiri.
Effective mechanism for quality feedback. Artinya, metrik harus
menyediakan para pengembang perangkat lunak dengan informasi
yang dapat meningkatkan kualitas produk akhir yang lebih baik.

23

Collection and Analysis Principles

Whenever possible, data collection and analysis should be automated;

Valid statistical techniques should be applied to establish relationship
between internal product attributes and external quality characteristics
Interpretative guidelines and recommendations should be established for
each metric
Bila mungkin, pengumpulan dan analisis data harus otomatis;
Sebaiknya diterapkan teknik statistik yang valid untuk membangun
hubungan antara atribut produk internal dengan karakteristik mutu
eksternal
Pedoman interpretasi dan rekomendasi untuk setiap metrik harus sudah
ditetapkan sebelumnya

24

23.2 Metrics for the Requirements Model

Function-based metrics: gunakan function-point titik fungsi

sebagai faktor normalisasi atau sebagai penentu "ukuran"
dari spesifikasi

Specification metrics: digunakan sebagai indikasi kualitas

dengan mengukur jumlah persyaratan menurut jenisnya

25

23.2.1 Function-Based Metrics

The function point metric (FP), pertama kali diperkenalkan oleh Albrecht
[ALB79], dapat efektif digunakan sebagai alat untuk mengukur
fungsionalitas yang ditawarkan oleh sistem.
Function-points diderivasi dengan menggunakan hubungan empiris
berdasarkan pengukuran yang dihitung langsung domain informasi
perangkat lunak dan penilaian terhadap kompleksitas perangkat lunak
Nilai domain Informasi domain didefinisikan berdasar:
number of external inputs (EIs)
number of external outputs (EOs)
number of external inquiries (EQs)
number of internal logical files (ILFs)
Number of external interface files (EIFs)

26

Function-Oriented Metrics

Function points are computed [IFP94] by completing the table shown in Figure
4.5. Five information domain characteristics are determined and counts are
provided in the appropriate table location. Information domain values are
defined in the following manner:
Number of external inputs: Dilakukan penghitungan terhadap setiap input
yang berbeda dari para pengguna yang memberikan data yang berorientasi
pada aplikasi yang berbeda ke perangkat lunak. Input harus dibedakan dari
inkuiri, yang akan dihitung secara terpisah.
Number of external outputs: Dilakukan penghitungan terhadap output para
pengguna yang memberikan informasi yang berorientasi pada aplikasi
terhadap user. Dalam hal ini, yang disebut output adalah reports, screens,
error messages, etc. Item data individual dalam laporan juga ikut dihitung.
Number of external inquiries: Inquiry didefinisikan sebagai input on-line yang
membangkitkan beberapa respon perangkat lunak yang langsung dalam
bentuk sebuah output yang on-line juga. Semua inquiry yang berbeda ikut
diperhitungkan.
Number of internal logical files: Dihitung semua master file yang ada (i.e., a
logical grouping of data that may be one part of a large database or a
separate file).
Number of external interface files: Dilakukan penghitungan terhadap semua
antarmuka mesin yang dapat dibaca (misalnya, file data pada media
penyimpanan) yang digunakan untuk mengirimkan informasi ke sistem.
27

Function Points

X
X
X
X

28

Jika data sudah terkumpul, kompleksitas dapat dihitung

berdasar jumlah masing-masing
Organisasi yang menggunakan metoda function-point
akan mengembangkan kriteria yang menentukan apakah
sebuah sistem bersifat simple, average, atau complex.
Perlu dicatat bahwa ketentuan tentang kompleksitas,
pada dasarnya bersifat subyektif.
Untuk menghitung function points (FP), digunakan
rumus sebagai berikut:
FP = count total [0.65 + 0.01 (Fi)] . (23-1)
dimana count total adalah jumlah dari semua FP
sistem yang diperoleh dari slide sebelumnya.
29

Sementara itu, Fi (i = 1 to 14) adalah "complexity adjustment values" yang

besarnya merupakan tanggapan dari pertanyaan-pertanyaan berikut ini
[ART85]:
1. Does the system require reliable backup and recovery?
2. Are data communications required?
3. Are there distributed processing functions?
4. Is performance critical?
5. Will the system run in an existing, heavily utilized operational
environment?
6. Does the system require on-line data entry?
7. Does the on-line data entry require the input transaction to be built over
multiple screens or operations?
8. Are the master files updated on-line?
9. Are the inputs, outputs, files, or inquiries complex?
10. Is the internal processing complex?
11. Is the code designed to be reusable?
12. Are conversion and installation included in the design?
13. Is the system designed for multiple installations in different
organizations?
14. Is the application designed to facilitate change and ease of use by the
user?

30

23.3 METRIC FOR THE DESIGN MODEL

Architectural Design Metrics

Metrics for OOD
Class Oriented Meytrics (The CK)
Class Oriented Meytrics (The MOOD)
OO Metrics
Componen-Level Design Metrics
Operation-Oriented Metrics
User Interface Metrics

31

23.3.1 Architectural Design Metrics

Architectural design metrics

Structural complexity = g(fan-out)
Data complexity = f(input & output variables, fan-out)
System complexity = h(structural & data complexity)
HK metric: architectural complexity as a function of fan-in and
fan-out
Morphology metrics: a function of the number of modules and
the number of interfaces between modules

32

23.3.2 Metrics for OO Design-I

Whitmire [Whi97] mendeskripsikan sembilan karakteristik

yang dapat diukur dan saling berbeda untuk pengukur OO
design:

Size
Size is defined in terms of
four views: population,
volume, length, and
functionality
Complexity
How classes of an OO
design are interrelated to
one another
Coupling
The physical connections
between elements of the

Ukuran didefiniskan menurut

populasi, volume, panjang, dan
fungsionalitas)
Bagaiman klas dari OOD saling
berinteraksi satu dengan
lainnya
Koneksi fisikal antar elemenelemen dalam OOD

33

23.3.2 Metrics for OO Design-I

Whitmire [Whi97] mendeskripsikan sembilan karakteristik yang dapat diukur dan

saling berbeda untuk pengukur OO design:

Sufficiency
the degree to which an
abstraction possesses the
features required of it, or the
degree to which a design
component possesses features
in its abstraction, from the point
of view of the current
application.
Completeness
An indirect implication about
the degree to which the
abstraction or design
component can be reused

Derajat yang ditentukan oleh apakah

sebuah memiliki fitur yang
dibutuhkan oleh sistem, atau derajat
yang menentukan seberapa jauh
komponen desain memiliki fitur-fitur
yang dinyatakan dalam abstraksi.
Semuanya diukur dari sudut pandang
aplikasi saat ini
Implikasi yang tidak langsung terkait
derajat yang ditentukan oleh
seberapa jauh abstraksi atau
komponen disain dapat dimanfaatkan.
34

Metrics for OO Design-II

Cohesion
The degree to which all
operations working together to
achieve a single, well-defined
purpose
Primitiveness
Applied to both operations and
classes, the degree to which an
operation is atomic
Similarity
The degree to which two or more
classes are similar in terms of
their structure, function, behavior,
or purpose
Volatility
Measures the likelihood that
a change will occur

Ditentukan oleh tingkat kemampuan

bekerja samanya semua operasi
dalam mencapai satu tujuan yang
didefinisikan dengan jelas
Diterapkan baik untuk operasi dan
kelas; menentukan tingkat ke atomikan sebuah operasi
Tingkat kesamaan dalam hal
struktur, fungsi, perilaku, atau tujuan
anantara dua kelas atau lebih
Mengukur kemungkinan bahwa akan
terjadi suatu perubahan
35

23.3.3 Class-Oriented Metrics

Proposed by Chidamber and Kemerer [Chi94]:
1.
2.
3.
4.
5.
6.

weighted methods per class

depth of the inheritance tree
number of children
coupling between object classes
response for a class
lack of cohesion in methods

1.
2.
3.
4.
5.
6.

metode bobot per kelas

kedalaman pohon inheritans
jumlah anak
kopling antara kelas objek
respon untuk sebuah kelas
Minimnya kohesi dalam metode

36

23.3.4 Class-Oriented Metrics

The MOOD Metrics Suite [Har98b]:

Method inheritance factor

Coupling factor
Polymorphism factor
Faktor inheritan metode
Faktor coupling
Faktor polimorfisme

37

23.3.5 Class-Oriented Metrics

Proposed by Lorenz and Kidd [Lor94]:

class size
number of operations overridden by a subclass
number of operations added by a subclass
specialization index

Ukuran kelas
Jumlah operasi yang digantikan oleh subclass
Jumlah operasi yang ditambahkan oleh subclass
Indeks spesialisasi

38

23.3.6 Component-Level Design Metrics

Cohesion metrics:
a function of data objects and the Fungsi dari objek data dan
locus of their definition
lokus definisi mereka
Coupling metrics:
a function of input and output
Fungsi dari parameter
parameters, global variables, and input dan output, variabel
modules called
global, dan modul yang
dipanggil
Complexity metrics:
hundreds have been proposed
(e.g., cyclomatic complexity)

banyak yang sudah

mengusulkan

39

23.3.7 Operation-Oriented Metrics

Proposed by Lorenz and Kidd [Lor94]:

Average operation size

operation complexity
average number of
parameters per operation

Ukuran rata-rata operasi

Kompleksitas operasi
Rata-rata jumlah parameter
per operasi

40

23.3.8 Interface Design Metrics

Layout appropriateness:
a function of layout entities,
the geographic position and
the cost of making
transitions among entities

merupakan fungsi dari tata

letak entitas, posisi geografis
dan "biaya" untuk membuat
transisi antar para entitas

41

23.4 Design Metrics for WebApps

Does the user interface
promote usability?
Are the aesthetics of the
WebApp appropriate for the
application domain and
pleasing to the user?
Is the content designed in a
manner that imparts the most
information with the least
effort?
Is navigation efficient and
straightforward

Apakah user interface

mempromosikan kegunaan?
Apakah estetika webapp yang
sesuai untuk domain aplikasi
dan menyenangkan bagi
pengguna?
Apakah konten yang dirancang
dengan cara yang paling
menanamkan informasi
dengan sedikit usaha?
Adalah navigasi yang efisien
dan mudah?
42

23.4 Design Metrics for WebApps

Has the WebApp architecture
been designed to
accommodate the special goals
and objectives of WebApp
users, the structure of content
and functionality, and the flow
of navigation required to use
the system
effectively?
Are
components
designed in a
manner that reduces
procedural complexity and
enhances the correctness,
reliability and performance?

Apakah arsitektur WebApp

telah dirancang untuk
mengakomodasi tujuan khusus
dan tujuan pengguna WebApp,
struktur isi dan fungsi, dan
aliran navigasi diperlukan
untuk menggunakan sistem
Apakah
komponen dirancang
secara efektif?
dengan cara yang mengurangi
kompleksitas prosedural dan
meningkatkan ketepatan,
keandalan dan kinerja?
43

23.5 Code Metrics

Halsteads Software Science:

a comprehensive collection of
metrics all predicated on the
number (count and occurrence) of
operators and operands within a
component or program

koleksi yang komprehensif sejumlah

metrik yang semua didasarkan pada
angka (cacah dan kejadian) dari
operator dan operan dalam
komponen-komponen atau program

It should be noted that Halsteads

laws have generated substantial
controversy, and many believe that
the underlying theory has flaws.
However, experimental verification
for selected programming
languages has been performed
(e.g. [FEL89]).

Perlu dicatat bahwa"hukum"

Halstead telah menimbulkan
kontroversi yang cukup luas, dan
banyak yang percaya bahwa teori
yang mendasarinya memiliki
berbagai kelemahan. Namun,
verifikasi eksperimental untuk
bahasa-bahasa pemrograman

44

23.6 Metrics for Testing

Testing effort can also be estimated using metrics derived

from Halstead measures
Binder [Bin94] suggests a broad array of design metrics that
have a direct influence on the testability of an OO system.
Lack of cohesion in methods (LCOM).
Percent public and protected (PAP).
Public access to data members (PAD).
Number of root classes (NOR).
Fan-in (FIN).
Number of children (NOC) and depth of the inheritance
tree (DIT).
45

23.7 Maintenance Metrics

IEEE Std. 982.1-1988 [IEE94] suggests a software maturity index

(SMI) that provides an indication of the stability of a software
product (based on changes that occur for each release of the
product). The following information is determined:
MT =the number of modules in the current release
Fc = the number of modules in the current release that
have been changed
Fa = the number of modules in the current release that
have been added
Fd = the number of modules from the preceding release
that were deleted in the current release
The software maturity index is computed in the following
manner:
SMI = [MT - (Fa + Fc + Fd)]/MT
As SMI approaches 1.0, the product begins to stabilize.
46

Soal 23.3

A system has 10 external input, 20 external output, fields 25

external queries, manages 4 internal logical files, and
interface with 4 different legacy systems (4 EIFs). All of these
data are average complexity, and the overall system is
relatively simple. Compute FP for the system.

Jawab:
Eis = 10; Eos = 20; Eqs = 25; ILFs = 4, EIFs = 4
Average 4
5
4
10
7
Ctotal = 40 + 100 + 100 + 40 + 28 = 308
FP = Ctotal x [0.65 + 0.01 x (Fi)]

Asumsi moderate = 46; simple = 28

FP = 308 X [0.65 + (0.01 x 28)] = 286.44
47

Soal 23.4

Software for system X has 24 individual functional (nf)

requirements and 14 nonfunctional requirements(nnf). What
is the specificity of the requirements? The completeness?

nf = 24

nnf = 14

nr = nf + nnf = 38

Q1 = nui/nr

Q2 = nu / (ni x ns)

Q3 = nc / (nc + nv)
48

Soal 23. 5 (Teori hal 624, pressman 7th)

A major information system has 1140 modules. There are 96 modules that
perform control and coordination functions and 490 modules whose
function depends on prior processing. The system process approximately
220 data objects that each has an average of three attributes. There are
140 unique database items and 90 different database segments. Finally
600 modules have single entry and exit points. Compute the DSQI for the
system.
S1 = 1140, S2 = 1140 96 = 1044, S3 = 490,

S4 = 220x3 = 660, S5 = 140, S6 = 90, S7 = 600

Asumsi (1) D1 = 1; wi = 0.167)

D2 = 1 S2/S1 = 0.085

D3 = 1 S3/S1 = 0.570

D4 = 1 S5/S4 = 0.788

D5 = 1 - S6/S4 = 0.864

D6 = 1 S7/S1 = 0.474

220 data object that each has an average of three attributes. There are

DSQI = 0.167 x 2.781(sigma wi di) = 0.464

49

Soal 23.6

A class X has 10 operations. Cyclomatic complexity has been

computed for all operations in the OO system, and the
average value of module complexity is 4. For class X, the
complexity for operations 1 to 10 is 5,4,3,3,6,8,2,2,5,5
respectively. Compute the weighted methods per class.
Jawab: 43
The number of methods and their complexity are a measure
of how much time and effort are required to develop and
maintain the class. The greater the number of methods in a
class the greater the potential impact on children because
they inherit all methods defined in the class . Classes with
large numbers of methods are likely to be more application
specific, limiting the possibility of reuse.
50

Soal 23.8

A legacy system has 950 modules. The latest release

required that 90 of these modules be changed. In addition, 50
new modules were added and 10 old modules were removed.
Compute the software maturity index for the system.

Mt = 950

Fc = 90

Fa = 50

Fd = 10

SMI = (Mt (Fc + Fa + Fd))/Mt = (950 150)/950 = 0.84

51