PENDEKATAN MODEL DAN METRIC UNTUK ESTIMASI

PROSES PERAWATAN PERANGKAT LUNAK

Rohman Dijaya, Daniel Oranova Siahaan, Ratih Nur Esti. A

Institut Teknologi Sepuluh Nopember

Kampus ITS, Jalan Raya ITS Sukolilo, Surabaya 60111
Tel: (031) 5939214; Fax: (031) 5913804
Email:rohman.dijhe.com, danielos@cs.its.ac.id, ratih_nea@if.its.ac.id

Abstrak
Perawatan perangkat lunak merupakan salah
satu bagian dari siklus hidup perangkat lunak
setelah proses pengembangan. Proses
perawatan membutuhkan upaya dan biaya
yang cukup besar dalam pelaksanaanya.
Tanpa adanya pengukuran perawatan
perangkat lunak yang jelas dan terperinci
akan menyebabkan efek domino dikemudian
hari bagi pengguna maupun pengembang.
Metric digunakan untuk proses estimasi waktu
maupun upaya perawatan perangkat lunak.
Model perawatan perangkat lunak digunakan
untuk memodelkan estimasi usaha dan biaya
dari perawatan perangkat lnak. Dengan
adanya model estimasi dari Proses Perawatan
system seperti Software Maintenance Effort
Estimation
Model(SMEEM)
akan
mempermudah proses pelaksanaan dan
pengawasan proses perawatan perangkat
lunak. Sedangkan dengan adanya metric akan
mempermudah estiamasi waktu perawatan
perangkat lunak.
Kata kunci : Estimasi perawatan perangkat
lunak, Metric, Model
1. Pendahuluan
Proses perawatan merupakan bagian
dari siklus hidup dari perangkat lunak, dimana
kegiatan itu meliputi proses perbaikan bugs,
koreksi kesalahan dan penambahan kinerja
perangkat lunak, selain itu, didalamnya
dikhususkan pada kegiatan yang bertujuan
meningkatkan fungsi dan nilai tambah dari
perangkat lunak itu sendiri. Proses perawatan

perangkat lunak tidak hanya menghabiskan

waktu dan tenaga dari pihak pengembang
maupun pelanggan, namun diperlukan biaya
yang berkelanjutan hingga proses perawatan
selesai. Semakin bagus pendekatan analisa
kebutuhan akan membuat proses perawatan
lebih efisien[1]. Membangun pemeliharaan
perangkat luna sangat penting bagi manajer
proyek untuk mengalokasikan personel dan
sumber daya untuk membangun tugas-tugas
pemeliharaan secara efektif , dan mengurangi
membangun pemeliharaan biaya yang
overhead pada tugas-tugas pembangunan
reguler , seperti memperbaiki kecacatan pada
fitur perangkatlunak dan menambahkan fitur
baru[11]. Namun estimasi usaha dari
perangkat lunak perawatan merupakan
tantangan bagi praktisi perangkat lunak karena
menghabiskan
setengah
dari
biaya
pengembangan secara keseluruhan[15].
Software Engineering Institute (SEI)
telah mengidentifikasi bahwa ada sebuah set
langkah khusus yang bisa digunakan untuk
mengukur proses perawatan, diantaranya ada
empat antara: ukuran, usaha, waktu dan
kualitas. Untuk mengaktifkan keempat
langkah disarankan melalui beberapa proses
perawatan perangkat lunak berikut: (1)
aktivitas perawatan perangkat lunak yang
didefinisi di semua organisasi perawatan, (2)
proses permintaan perubahan, dan(3)sistem
pencatatan waktu[2]. Model Perawatan
perangat lunak merupakan suatu permodelan
yang digunakan untuk mengestimasi effort
dari perawatan system pada paper ini adalah
Software Maintenance Effort Estimation
Model (SMEEM)[6]. Sedangkan metric atau
lebih dikenal dengan software maintenance
size metric merupakan salah satu ukuran untuk
memprediksi effort dan time dari system
perawatan, beberapa metric yang umum

digunakan antara lain adalah MS-Loc, MSTC, MS-TM, MS-MC dan MS-WMC[19].
Selain melalui model dan metric terdapat jga
teknk estimasi perawatan perangkat lunak
yaitu elalui teknik refactoring[17]. Namun
focus dari paper ini adalah mengevaluas
pendekatan metric dan model. Kesemua
literatur dari model dan metric akan dijabarkan
pada sesi kedua. Detail dari model dan metric
untuk estimasi perangkat lunak akan
dijelaskan lebih lanjut pada sesi ketiga serta
pada sesi keempat akan dipaparkan
kesimpulan mengenai fungsi metric dan model
pada estimasi perawatan perangkat lunak.
2. Dasar Teori
2.1 Proses Perawatan Perangkat Lunak
Perbedaan jenis dan sifat tugas
anatara pengembangan perangkat lunak dan
pemeliharaan adalah pada pemilihan metode
dan prosedur untuk menangani setiap tugas
yang
terpisah[13].
Pada
estimasi
pengembangan
perangkat
lunak
mengkalkulasikan nilai yang paling realistis
dari upaya yang dibutuhkan pengguna untuk
mengembangkan atau memelihara software
yang belum dikembangkan[12]. Berdasarkan
ISO/IEC 14764 ada sebelas istilah pada
perawatan system proses antara lain[8]:
1. Perawatan Adaptif yaitu pemeliharaan
perangkat lunak setelah perangkat lunak
dilahirkan untuk menjaga perangkat lunak
stabil dari adanya perubahan lingkungan
2. Perawatan Corrective yaitu modifikasi
reaktif perangkat lunak yang dilakukan setelah
melahirkan untuk memperbaiki masalah yang
ditemukan setelah proses impelemntasi
3. Perawatan Emergency yaitu modifikasi
terjadwal dilakukan untuk menjaga sistem
operasional menjadi pending, perawatan ini
merupakan bagian dari perawatan corrective.
4. Maintanbility yaitu kemampuan produk
perangkat lunak untuk dapat dimodifikasi
5. Perawatan Enhancement yaitu modifikasi
perangkat lunak untuk memenuhi persyaratan
baru
6. Modification Request adalah istilah generik
yang digunakan untuk mengidentifikasi
modifikasi yang diusulkan untuk produk
perangkat lunak yang sedang dipelihara
7. Perawatan perfective modifikasi produk
perangkat lunak setelah melahirkan untuk
mendeteksi dan memperbaiki kesalahan laten

dalam perangkat lunak produk sebelum

mereka dinyatakan sebagai kegagalan
8. Perawatan Preventif merupakan modifikasi
produk perangkat lunak setelah dilahirkan
untuk mendeteksi dan memperbaiki kesalahan
laten dalam perangkat lunak produk sebelum
mereka menjadi kesalahan operasional
9. Problem Report merupakan istilah yang
digunakan untuk mengidentifikasi dan
menjelaskan masalah yang terdeteksi pada
produk perangkat lunak
10. Perawatan Perangkat lunak totalitas
kegiatan yang dibutuhkan untuk memberikan
dukungan biaya - efektif untuk sistem
perangkat lunak
11. Transisi perangkat lunak adalah urutan
tindakan yang terkontrol dan terkoordinasi
dimana pengembangan perangkat lunak lewat
dari organisasi melakukan pengembangan
perangkat lunak awal untuk organisasi
perangkat lunak melakukan pemeliharaan.
2.2 Pengukuran Perawatan Perangkat
lunak
Kualitas proses perawatan perangkat lunak
semakin menjadi perhatian bagi masyarakat
dan tim IT[4]. Karena akan mempengaruhi
kenerjadari sebuah organisasi. Usaha dan
waktu perawatan merupakan upaya yang
diperlukan untuk mengembangkan atau
memelihara perangkat lunak tergantung pada
kompleksitas yang belum dikembangkan pada
perangkat lunak[15]. Estimasi usaha dan
waktu perawatan perangkat lunak merupakan
proses kerja dari proses perawatan perangkat
lunak yang dilakukan oleh stakeholder
perangkat lunak. Faktor yang mempengaruhi
adanya estimasi perawatan perangkat lunak
diantaranya: kualitas dokumentasi, struktur
sistem,
modularitas,
usabilitas
modul
perangkat lunak yang ada, kesesuaian dengan
standar rekayasa perangkat lunak, keakraban
dengan bahasa pemrograman, kemampuan
untuk berubah-ubah/kemampuan dibaca oleh
bahasa pemrograman dan pengetahuan
domain[6]. Usaha perawatan perangkat lunak
dapat diestimasikan menggunakan beberapa
model dan metric. Beberapa penelitian
sebelumnya telah menunjukkan implementasi
dari model ataupun metric yang digunakan
untuk estimasi ataupun prediksi usaha
perawatan perangkat lunak pada objek dan
kasus
yang
berbeda
[3];[5];[9];[10];[14];[20];[21].

2.3. Model Estimasi Usaha Perawatan

Perangkat Lunak
Software Maitenance Effort Estimation
Model (SMEEM) merupakan salah satu
metode estimasi yang digunakan untuk
mengestimasi usaha dari perawatan perangkat
lunak, dimana pada proses estimasi dari
metode ini didasarkan pada faktor yang
mempengaruhi estimasi perawatan perangkat
lunak. Pada industri perangkat lunak terdapat
pendekatan untuk mengestimasi usaha
perawatatn yang berbasis pada proses
pengembangan perangkat lunak secara
tradisional. Pendekatan SMEEM membagi
proses perawatan menjadi 5 langkah yang
akan dijelaskan pada sesi ke III.
2.4 Metric Ukuran Perawatan Perangkat
Lunak
Metric ukuran perangkat lunak dapat
digunakan
untuk
memprediksi
upaya
perawatan ataupun waku perawatan. Untuk
mengestimasi waktu dari perawatan proses
digunakan metric yang didasarkan pada
perubahan class dan method selama proses
perawatan
perangkat
lunak.
Konsep
perhitungan estimasi upaya dan waktu
perawatan perangkat lunak menggunakan
metric didasarkan pada perubahan parameter
metric yang terjadi selama proses perawatan,
parameter tersebut diantaranya:
1. Metric jumlah baris kode program
2. Metric jumlah kelas program
3. Metric jumlah method program
4. Metric jumlah rata-rata jumlah method
per kelas
5. Metric bobot method pada setiap kelas
Pendekatan mengenai 5 parameter dasar
metric untuk mengukur usaha dan waktu
estimasi perawatan perangkat lunak dijabarkan
lebih lanjut pada sesi ke III.
3.

PEMBAHASAN

3.1 Pendekatan Permodelan Perawatan

dengan SMEEM
SMEEM adalah pendekatan untuk
mengestimasi proses perawata perangkat lunak
yang menggunakan RC Stories (Catatan
Kebutuhan) dan software yang versi
sebelumnya
sebagai
input
kemudian
melakukan beberapa fase proses estimasi.
Adapun fase dari SMEEM terbagi menjadi

lima fase yang dijelaskan dibawah ini :

1. Factor Count (FC) Computaton
FC Merupakan komputasi dari keseluruhan
somasi nilai VAF, sedangkan nilai VAF(Value
Adjusmet Factor) merepresentasikan nilai
General System Charcteristic(GCS) yang
dijadikan sebagai tingkat fungsional umum
dari aplikasi yang dihitung. Adapun formula
dari FC adalah sebagai berikut
Factor Count (FC) = i=1..7 VAFi

2. Story Point Assignment

Menetapkan Story Point( SP ) ke setiap story
berdasarkan ukuran penggunaan teknik
Planning poker oleh tim pemeliharaan.
3. Adjusted Story Point (ASP)
Setelah Story Point dilakukan penugasan
dengan teknik Planning poker maka nilai ASP
selanjutnya dapat dikomputasikan dengan
formula berikut
ASP= SP-[Critical Factor * ((FC * Max_VAF) / (FC + Max_VAF)) ]

4. Menghitung Size of Maintenance(SOM)

SOM dapat dikomputasikan melalui formula
berikut
Size of Maintenance (SoM) = i=1..n ASP i

Dimana ASPi adalah ASP dari i yang pertama

pada RC story dan n adalah jumlah total RC
stories pada maintenance project
5. Menghitung Durasi Perawayan(DOM)
Menghitung DOM berdasarkan nilai SOM dan
ASP yang dikembangkan pada setiap iterasi.
Biaya RC story tunggal atau komponen proyek
pemeliharaan dapat dihitung dari atas DoM
dan imbursement saat dibayarkan kepada
pengelola. Pada penjumlahan akhir dari semua
biaya RC Story menyediakan keseluruhan
biaya pemeliharaan untuk proyek
3.2 Pendekataan Maintenance Size Metric
untuk Estimasi Usaha dan Waktu
Pendekatan maintenance size metric
mendasarka 5 metric sebagai parameter
perhitungan yang biasanya cukup efektif untuk
estimasi perangkat lunak yang berorientasi
objek. 5 metric yang digunakan sebagai dasar
estimasi tersebut dijelaskan sebagai berikut :
1. Metric jumlah baris kode program(MS LOC)

Pada metric ini menghitung rasio dari

penambahan dan perubahan baris kode
terhadap total jumlah baris program awal
secara keseluruhan. Formula yang digunakan
adalah sebagai berikut
MS-LOC=

(WeightedMethodChanged) Number Class of Change

MS-WMC=
()

LOCAdded+LOCModified
Total Line Code pada Program Awal

Metric total jumlah kelas program(MSTC)

Pada metric ini menghitung rasio perubahan
kelas terhadap jumlah kelas program awal
secara keseluruhan. Formula yang digunakan
adalah sebagai berikut

Total Class in the initial system

2.

|ClassAdded ClassDeleted|+ClassModified
MS-TC=
Total Class pada Program Awal
Metric total jumlah method program(MSTM)
Pada metric ini menghitung rasio perubahan
method terhadap jumlah method program awal
secara keseluruhan. Formula yang digunakan
adalah sebagai berikut
|MethodAdded MethodDeleted|+MethodModified
MS-TM=
3.

Total Method pada Program Awal

Metric total jumlah method perkelas

program(MS-MC)
Pada metric ini menghitug rasio total
perubahan jumlah method perkelas terhadap
jumlah total method perkelas pada program
awal secara keseluruhan. Formula yang
digunakan adalah sebaga berikut
6.

MS-MC=

(MethodChanged) Number Class of Change

()

Total Class in the initial system

7.

Metric berdasarkan tingkat bobot method

perkelas MS-WMC
Metric ini merupakan pengembangan dari MSMC dimana pada metric ni memperhitungkan
tingkat bobot dari suatu method pada kelas.
Pada metric ini menghitung rasio perubahan
bobot method pada setiap kelas terhadap
perubahan total dari keseluruan bobot method
program awal. Formula yang digunakan
adalah sebagai berikut

4. HASIL PEMBAHASAN
4.1 Evaluasi dari SMEEM
Berdasarkan penelitan mengenai
SMEEM dihasilkan hasil evaluasi[6]. Hasil
evaluasi yang dilakukan penulis menyatakan
RC sebagai artefak persyaratan dalam proyek
pemeliharaan dengan memiliki story point 20
sebagai contoh. Kategori proyek pemeliharaan
termasuk aplikasi berbasis web, MIS dan
proyek kritis dengan CF .60 , .35 dan .20.
Kinerja pendekatan yang diusulkan untuk
pemeliharaan telah diteliti untuk berbagai
tingkat intensitas VAF. Nilai-nilai ASP telah
dihitung dengan menggunakanm odel yang
diusulkan pada tingkat intensitas yang berbeda
dari VAF untuk berbagai kategori proyek.
Tabel 1 menunjukkan perhitungan ASP untuk
contoh memiliki Kisah Titik ( SP ) 20. Untuk
contoh ini , dalam sebuah proyek penting
dengan masukan CF tertentu adalah 0,20 , dan
ASP telah dihitung sebagai 16.88 . Telah
diamati bahwa masuknya VAF dan CF dalam
proyek tersebut mengubah perkiraan ASP
sekitar 84,4 % dari SP sebelumnya dan
estimasi nilai yang lebih realistis . Pengukuran
kinerja SMEEM ditunjukkan pada Gambar 1
dengan tiga nilai Faktor Hitungan ( FC ) , yang
merupakan penjumlahan dari VAF sebagai
sumbu X , ASP sebagai sumbu Y keduanya
sehubungan dengan Faktor kritis ( CF ) , yang
menunjukkan kategori proyek.
Tabel1. Komputasi dari of ASP dengan setiap
contoh dari Story point 20
FC
7
10
14
18
21
25
28
31
35

CF=0.60

CF=0.35

CF=0.30

15.33
14.00
12.86
12.12
11.25
10.67
10.13
09.50

17.28
16.50
15.84
15.41
14.89
14.55
14.24
13.87

18.44
18.00
17.62
17.37
17.08
16.88
16.71
16.50

16.50

17.96

18.83

100% dari kode, maka dibutuhkan 55 x 0.32

jam untuk mengembangkan ekstra tambahan 32%
lebih kode yang dibutuhkan waktu sekitar 17.32
jam.

Gambar1. Grafik yang menunjukkan hasil

perhitungan ASP[19].
4.2 Evaluasi dari Maintenance Size Metric
Berdasarkan penelitian mengenai
Maintenance size metric dihasilkan hasil
evaluasi[19].
Hasil
evaluasi
penulis
memaparkan bahwa berdasarkan data yang
dikumpulkan secara empiris selama proses
pengembangan dan perawatan perangkat lunak
dalam kasus ini adalah pada perusahaan HDD
yang didokumentasikan dalam gambar 2,
terdapat 4 versi perangkat lunak yang terdiri
dari sebuah perangkat lunak versi awal dan 3
perangkat lunak versi pengembangan. Hasil
evaluasi digambarkan dengan tabel 2 yang
menggambarkan nilai dari lima basis metric
untuk perawatan perangkat lunak, nilai
tersebut didapatkan dari waktu pengembangan
program versi awal.

Nilai Estimasi dari waktu perawatan

perangkat lunak berdasarkan metric yang
dibandingkan dengan waktu perawatan yang
sebenarnya digambarkan pada
Gambar
3(a,b,c).

Gambar 3.a Perawatan/modifikasi versi 1

Gambar 3.b. Perawatan/Modifikasi versi 2

Gambar2. Data Pengembangan dan Perawatan

Perangkat lunak pada perusahaan HDD[19]
Tabel2. Nilai dari 5 Maintenance Size Metric
dan hasil prediksi dari 3 versi software
modifikasi
Type

Maintenance
Version 1

Maintenance
Version 2

Maintenance
Version 3

MS

EMT

MS

EMT

MS

EMT

MS-LOC

0.32

17h.36m

0.1

7h.36m

0.01

41m

MS-TC

0.23

12h.39m

0.13

8h.21m

0.50

34h.54m

MS-TM

0.21

11h.33m

0.09

5h.46m

0.13

8h.52m

MS-MC

0.18

9h.54m

0.08

5h.8m

0.12

8h.11m

MS-WMC

024

13h.12m

0.09

5h.46m

0.03

2h.30m

Gambar 3.c. Perawatan/Modifikasi versi 3

Prediksi Waktu Perawatan

Waktu Perawatan Aktual

Ms = Maintenance Size, EMT = Estimasi Wakti, h = jam, m= menit

Estimasi waktu perawatan menggunakan

sebuah aturan sederhana dan tiga proporsi.
Sebagai contoh, nilai 0,32 pada MS-LOC
mengindikasi bari kode pada perawatan/
modifikasi versi 1 dengan pertumbuhan 0,32
dari versi awal. Jika pada waktu versi awal
membutuhkan 55 jam untuk mengembangkan

Dalam Gambar 3a , metrik MS - MC

memprediksi waktu pemeliharaan 9 jam 54
menit, paling dekat dengan yang sebenarnya
yaitu waktu pemeliharaan 9 jam 21 menit.
Metrik terbaik berikutnya adalah MS - TM dan
MS - TC ,dst. untuk pemeliharaan versi 2 ,

angka 3b menunjukkan bahwa MS - MC juga

melakukan estimasi pemeliharaan yang lebih
baik daripada metrik lainnya. Yang terbaik
berikutnya metrik adalah MS - TM dan MS WMC. Untuk pemeliharaan versi 3 , angka 3c
menunjukkan bahwa MS LOC diprediksi
waktu pemeliharaan menjadi 41 menit
sementara waktu actual adalah 1 jam 10 menit.
MS - WMC diprediksi 2 jam 30 menit ,
memberikan nilai terdekat berikutnya dengan
waktu pemeliharaan yang sebenarnya.
5.

AlShayeb, M. (2013). On the

relationship of class stability and
maintainability. iet-sen , 339-347.

[4]

Andressa Ianzen, E. C. (2013).

Software process improvement in a
financial organization:An action
research approach. Elseiver , 54-65.

[5]

Bhattacharya, P. (2011). Using

Software Evolution History to
Facilitate Development and
Maintenance. ACM , 1122-1123.

[6]

Choudharia, J., & Sumanb, D. U.

(2012). Story Points Based Effort
Estimation Model for Software
Maintenance. Elsivier , 761-765.

[7]

Hurdugaci, V., & Zaidman, A. (2012).

Aiding Software Developers to
Maintain Developer Tests. CSMR , 1120.

[8]

ISO/IEC 14764. (2006). Software

Engineering Software Life Cycle
Processes-Perawatan . Geneva:
ISO/IEC.

[9]

Kula, R. G., Fushida, K., Yoshida, N.,

& Iida, H. (2012). Experimental Study
of Quantitative Analysis of
Mantenance Effort using Program
Slicing-based Metrics. APSEC , 50-57.

[10]

Kurtel, K. (2013). Measuring and

Monitoring Software Maintenace.
IWSM.Mensura , 247-252.

[11]

McIntosh, S. (2011). Build System

Maintenance. ICSE-ACM , 1167-1169.

[12]

Midha, V., & Bhattacherjee, A.

(2012). Governance practices and
Software Maintenance: A study of
open source projects. Elsivier , 23-32.

[13]

Rashid, A., Wang, W. Y., & Dorner,

a. D. (2009). Gauging the Differences
between Expectation and Systems Sup
port: the Managerial Approach of

KESIMPULAN

Berdasarkan hasil evaluasi dari Model

SMEEM didapatkan kesimpulan bahwa
SMEEM merupakan model estimasi upaya
perawatan
perangkat
lunak
yang
menggabungkan VAF dengan intensitas yang
berbeda sehingga dapat diilustrasikan pada
berbagai jenis proyek pemeliharaan. Hal ini
dirancang untuk membantu manajer proyek
yang bertanggung jawab. Dalam pemeliharaan
perangkat lunak untuk menghitung upaya
pemeliharaan perangkat lunak diperkirakan
dalam hal ASP , ukuran, biaya dan durasi. Hal
ini menghasilkan hasil estimasi yang lebih
realistis dan tepat . Model ini hanya berlaku
untuk lingkungan pemeliharaan berbasis agile
dan pemrograman ekstrim. Kemudian untuk
estimasi waktu perawatan perangkat lunak
dapat menggunakan maintenance size metric
karena dianggap lebih efisien terutama untuk
program yang berorientasi objek.
Kedepannya
model
ini
akan
dikembangkan dengan perbaikan SMEEM
yang menggunakan faktor lain dari agile dan
XP environment. Kemudian metric ini akan
dikembangkan
lebih
lanjut
untuk
pengembangan berbagai jenis program.
6.

[3]

DAFTAR PUSTAKA

[1]

Abhilasha, & Sharma, A. (2013). Test

Effort Estimation in Regression
Testing. International Conference in
MOOC, Innovation and Technology in
Education (MITE , 343-348).

[2]

Alain April, P. (2010). Studying

Supply and Demand of Software
Maintenace and Evolution Services.
Quatic , 352-357.

Adaptive and Perfective Software

Maintenance . Coinfo , 45-50.
[14]

Sharmaa, A., & Kushwaha, D. S.

(2012). Estimation of Software
Development Effort from
Requirements Based Complexity.
Elsevier , 716-722.

[15]

Tripathi, A., Kumar, B., Sharma, A.,

& Kushwaha, D. S. (2012). SRS
Based Estimation of Software
Maintenance Effort. ICCCT , 154-155.

[16]

Varro, D. (2012). A bridge over

troubled water - Synergies between
model transformation and Software
Maintenance techniques. CSMR , 5-6.

[17]

Villavicencio, G. (2012). A New

Software Maintenance Scenario Based
on Refactoring Techniques. CSMR ,
341-346.

[18]

Wei, K., Crowston, K., Li, N. L., &

Heckman, R. (2014). Understanding
group maintenance behavior in
Free/Libre Open-Source Software
projects: The case of Fire and Gaim.
Elsevier , 297-309.

[19]

Wirotyakun, A., & Netisopakul, P.

(2012). Improving Software
Maintenance Size Metrics A Case
Study: Automated Report Generation
System for Particle Monitoringin Hard
Disk Drive Industry. JCSSE , 334-339.

[20]

Yongchang, R., Zhongjing, L., Tao,

X., Xiaoji, C., & Xiaoji, C. (2011).
Perangkat lunak Perawatan Process
Model and Contrastive Analysis. ICIII
, 169-172.

[21]

Yu, S. (2012). Retrieving Software

Maintenance History with Topic
Models. ICSM , 621-624.