7/26/2019 Rangkuman Software Evolution and Maintenance
http://slidepdf.com/reader/full/rangkuman-software-evolution-and-maintenance 1/17
Perangkat lunak Evolution and Maintenance
Pendahuluan
Perangkat lunak yang sukses membutuhkan perulangan perubahan (Evolusi)
yang dipicu oleh perubahan persyaratan, teknologi, dan pengetahuan
stakeholder. Paper ini membahas beberapa aspek evolusi perangkat lunak.Secara khusus, disajikan model baru dari perangkat lunak lifespan, yang disebut
staged model, yang mengklarikasi peran evolusi perangkat lunak dan
pelayanan perangkat lunak (maintenance) dalam perangkat lunak lifecycle. !al
ini disajikan juga model tentatif dari tugas evolusi yang paling penting. Makalah
ini membahas pengembangan lebih lanjut dari tema"tema selama #$ tahun
terakhir dan juga arah kedepannya. Selain itu membahas tema baru terkait yang
telah muncul atau menjadi penting.
Secar histori, evolusi perangkat lunak muncul sebagai fenomena yang tak
terduga dan tidak terencana yang telah diamati dalam studi kasus a%al. Sejak
saat itu, menjadi penting dan menjadi pusat perhatian dari pembuat perangkatlunak. &da beberapa ringkasan terbaru yang dipetakan dalam bidang evolusi
perangkat lunak ' odfrey dan erman membandingkan evolusi perangkat lunak
dan pemeliharaan perangkat lunak, dua istilah yang beberapa penulis salah atau
tertukar. Mens dan emeyer menyunting sebuah buku yang membahas masalah"
masalah penelitian dalam evolusi perangkat lunak, rekayasa ulang, dan
sebagainya. Makalah ini didasarkan pada ringkasan ini, memetakan kondisi
sekarang dari tema evolusi perangkat lunak yang dipilih, dan menguraikan arah
kedepannya.
Mungkin kemajuan paling signikan sejak *+oadmap makalah tentang
keunggulan baru dari evolusi pengembangan perangkat lunak. -ni mentransfersebagian besar pengembangan perangkat lunak ke tahap evolusi perangkat
lunak dan merubah arus utama rekayasa perangkat lunak. Evolusi
pengembangan perangkat lunak meliputi agile development, open source
development, dan proses lainnya. -su"isu yang berkaitan dengan staged model
didiskusikan pada bagian .
Penelitian dari tugas mendasar dari evolusi perangkat lunak, perubahan
perangkat lunak, juga secara substansial berkembang. /ondisi dan arah
kedepannya dirangkum pada 0agian 1.
Pengembangan lain yang siginikan dalam kurun %aktu ini yaitu metodologi
penelitian. ibahas pada 0agian $. 0agian 2 mendiskusikan tempat evolusiperangkat lunak dalam kurikulum sarjana. 0agian 3 membahas pera%atan
perangkat lunak sebagai perbandingan evolusi perangkat lunak. 0agian 4
kesimpulan dari makalah.
Staged Model dari Perangkat lunak 5ifespan
Perangkat lunak 5ifespan dibagi menjadi lima langkah ' initial development,
evolution, servicing, phase out, dan close"do%n. isajikan pada ambar #.
7/26/2019 Rangkuman Software Evolution and Maintenance
http://slidepdf.com/reader/full/rangkuman-software-evolution-and-maintenance 2/17
-nitial development menghasilkan versi a%al dari perangkat lunak. Pengembang
memilih 0ahasa pemrograman, library, perangkat lunak tools, arsitektur sistem,
dan sebagainya. Pilihan fundamental dari initial development menetapkan kursus
untuk semua perangkat lunak lifespan6 pembalikan keputusan ini belakangan
sangat mahal, dan dalam penerapan tidak mungkin. -nitial developmentbiasanya berisi tugas yang familiar %aterfall (perencanaan perangkat lunak,
persyaratan elisitasi, desain, dan implementasi), tetapi ruang lingkup dan durasi
terbatas, meninggalkan sebagian besar pengembangan untuk perubahan. 7ntuk
pembahasan isu dalam initial development dan perannya dalam konteks staged
model , dilihat pada 0ab #$ of 89.
Evolusi merupakan topik utama dalam makalah ini. Para pengembang
menambahkan tur baru, memperbaiki kesalahan sebelumnya, dan bereaksi
dengan re:uirements, teknologi, dan pengetahuan volatilitas sebagai
memainkan melalui %aktu. Perubahan perangkat lunak blok pembangunan dasar
dari evolusi perangkat lunak dan setiap perubahan memperkenalkan tur baruatau beberapa property baru lainnya ke dalam perangkat lunak.
Pemeliharaan atau servis, programmer tidak lagi melakukan perubahan besar
dalam perangkat lunak, tetapi mereka tetap membuat perbaikan kecil agar
perangkat lunak tetap dapat digunakan. Perangkat lunak dalam tahap servis
disebut *5egacy perangkat lunak, *aging perangkat lunak, atau *perangkat
lunak in maintenance.
/etika perangkat lunak tidak layak dari setiap perbaikan lebih lanjut, ini
memasuki tahap fase out dimana ia tidak lagi dilayani, meskipun masih bisa
digunakan. 5alu, para manajer atau pelanggan benar"benar menarik sistem dari
produksi dan disebut close"do%n.
7/26/2019 Rangkuman Software Evolution and Maintenance
http://slidepdf.com/reader/full/rangkuman-software-evolution-and-maintenance 3/17
ari sudut pandang rekayasa perangkat lunak, evolusi perangkat lunak adalah
tahap utama dari perangkat lunak lifespan6 untuk perangkat lunak yang sukses,
menghabiskan %aktu dan sumberdaya dalam jumlah yang banyak dalam evolusi
dan karena itu membutuhkan perhatian khusus dari peneliti.
.#. Evolutionary Perangkat lunak evelopment
ES adalah praktek pengembangan perangkat lunak yang sebagian besar
bergerak dalam pengembangan dari initial development untuk evolusi. -nitial
development singkat dan a%al dimulainya evolusi adalah respon terhadap
volatilitas persyaratan, teknologi, atau pengetahuan dan mena%arkan
pengembang untuk mungkin bereaksi terhadap volatilitas secara tepat %aktu
dan mena%arkan stakeholder umpan balik berulang tentang kemajuan proyek.
/etika pengetahuan tentang proses ES dapat ditelusuri ke a%al sejarah
pengembangan perangkat lunak, proses ES baru dan popular muncul dalam
dua dekade terakhir dan menjadi pusat dari pengembangan perangkat lunak.
Semua proses ES berbagi praktek evolusi perangkat lunak, namun berbeda dariaspek lain. 0agian ini berisi daftar proses ES.
-terative development ditandai dengan iterasi berulang. -terasi merupakan
tonggak dengan tujuan spesik dan menghasilkan e;ecutable (bisa dikerjakan) <
meskipun tidak lengkap < versi perangkat lunak yang diberikan ke stakeholder
untuk memberikan kesempatan menilai keadaan proyek dan rencana untuk
iterative development yang telah digunakan sejak a%al pengembangan
perangkat lunak meskipun telah terkenal akhir"akhir ini.
&gile development adalah tipe yang banyak dibahas dari iterative development
yang didasarkan pada iterasi yang sangat singkat dan pembuatan keputusan
mandiri oleh tim pengembang selama iterasi. =ontoh ' Scrum dan E;tremeProgramming.
E;ploratory development digunakan ketika pengembang tidak tahu detail a%al
dari tur yang mereka kembangkan dan mereka membangun dengan trial"and
eror. Esploratory development sangat umum dalam proyek penelitian.
=entrali>ed development ditandai dengan kehadiran %ali dari basis kode yang
menerima atau menolak perubahan terhadap basis kode, menghapus yang
benar dari pengembangan individu. iharapan perangkat lunak dengan kualitas
yang sangat tinggi, termasuk perangkat lunak avionics, adalah contoh dari
proyek"proyek tersebut.?pen source development adalah varian yang banyak dibahas dari centrali>ed
development dimana pengembang dari masyarakat luas dapat menyumbang
kode mereka ke proyek, tetapi pemilik kode menjaga basis kode dan menerima
atau menolak kontribusi ini.
-nner source development memanfaatkan alat"alat dan teknik open source
development, tetapi dilakukan dalam sebuah perusahaan untuk pengembangan
perangkat lunak kepemilikan. Proyek yang sukses dilakukan dengan cara ini.
irected development dimana manajer memberikan tugas kepada para
pengembang. @elah digunakan secara default ketika proses lain tidak berlaku danini berlaku untuk proyek"proyek yang sangat besar atau terdistribusi.
7/26/2019 Rangkuman Software Evolution and Maintenance
http://slidepdf.com/reader/full/rangkuman-software-evolution-and-maintenance 4/17
Solo development adalah proses yang dilakukan oleh programmer tunggal6
dengan ketersediaan alat"alat baru dan library yang po%erful, proses ini menjadi
lebih dan lebih umum.
Semua proses pengembangan perangkat lunak merupakan varian dari perangkat
lunak evolution dan dibagi menjadi karakteristik fundamental, yang setiap
perubahan diulang dari perangkat lunak yang ada. Pengembang perangkat lunak
harus memilih varian ES yang paling tepat sesuai keadaan proyek.
Proses ES meningkatkan kemungkinan keberhasilan dari proyek perangkat
lunak yang kecil. ata menunjukkan bah%a proyek kecil (A # juta dolar)
sekarang memiliki tingkat keberhasilan yang belum pernah terjadi sebelumnya
yaitu 43B, dan hanya $B yang dibatalkan.
. Cuture irections in Staged Model
..# @o%ards 7nbundling Practices of ES
Proses ES yang telah dijelaskan adalah semua kasus yang berbeda dari evolusiperangkat lunak, tiap proses berbeda satu sama lain. Mereka sering disajikan
sebagai sebuah paket tetap dari praktek dan praktisi diharapkan menerima atau
menolak seluruh bundle. Damun bundling ini < sementara itu merupakan tahap
yang masuk akal dalam pemahaman kita tentang evolusi perangkat lunak <
menjadi kendala untuk kemajuan. 0agian ini menyajikan tampilan yang
berbeda ' -ni mengusulkan untuk mengasosiasikan praktik individu dengan
keadaan proyek yang mereka tangani dan berdasarkan itu, untuk menyesuaian
proses baru yang tepat sesuai dengan kebutuhan proyek tertentu.
/ami mencatat bah%a setiap proyek ES memiliki daftar panjang praktek.
0eberapa dari mereka jelas dan muncul dalam semua proyek yang %ajar,sementara yang lain adalah respon terhadap situasi tertentu yang tim ES harus
hadapi. Praktek dibagi menjadi tiga kelompok'
#. Praktek pengembangan kode. Praktek organisasi tim pengembang1. Praktek yang melibatkan stakeholder
=ontoh praktek pengembangan kode meliputi praktek verikasi kode, konvensi
penamaan, dan sebagainya.
Praktek organisasi tim pengembang meliputi praktek tata kelola tim
pengembang. Misalnya tugas"tugas dapat dilakukan oleh manajer atau dapatdilakukan secara mandiri oleh pengorganisasian tim pengembang.
Praktek yang melibatkan semua stakeholder meliputi perencanaan iterasi tujuan
dan lamanya, keputusan tentang rilis produk, prioritas evolusi tugas, dan
sebagainya.
Pada a%al proyek pengembangan perangkat lunak baru, praktek penting
menarik batas yang benar antara initial development dan evolusi. Pada saat
penentuan batas ini, ada dua pertimbangan yang bertentangan ' i satu sisi,
initial development harus menyelesaikan masalah yang paling krisis dan
mengatur proyek pada bagian yang baik. &gar adil, kriteria ini membutuhkan
initial development berukuran besar. isisi lain, pengembang butuh umpan baliktepat %aktu dari stakeholder tentang arah proyek dan harus menanggapi
7/26/2019 Rangkuman Software Evolution and Maintenance
http://slidepdf.com/reader/full/rangkuman-software-evolution-and-maintenance 5/17
volatilitas6 ini membutuhkan initial development yang singkat. 0atasan yang
benar antara initial development dan evolusi mendamaikan kedua pertimbangan
yang bertentangan. iskusi yang luas dari masalah ini telah dilakukan
dimasyarakat dimana banyak penulis mencoba menggabungkan desain
pengguna terpusat dengan agile development.
Damun ini adalah permasalahan umum dari semua ES dan layak mejadi
perhatian tambahan peneliti.
@abel # menyajikan contoh dari situasi proyek dan praktik sesuai yang
membahas mereka. -ni merupakan versi a%al6 upaya penelitian besar diperlukan
untuk mendapatkan tabel masa depan yang komprehensif dan praktis berguna.
0eberapa penulis melakukan pekerjaan yang luas pada menggambarkan factor
yang mencirikan keadaan proyek dan juga dicatat bah%a beberapa keadaan
mungkin tidak memiliki praktik yang cocok meringankan yang cocok. Damun,
demikian tabel kredibel yang meluas @abel - dan memperhitungkan berbagai
tahap perangkat lunak lifecycle, mungkin secara substansial dampak ES dan
praktek rekayasa perangkat lunak di masa depan.
@abel #. @abel a%al dari praktik ES sebagai ja%aban atas keadaan proyek
/eadaan Proyek Praktik yang sesuai untuk keadaanEksplorasi Pemrograman diperlukan Pengembanga sebagai domain e;pert/esenjangan antara programmer dan
kualitas yang diharapkan
ali /ode, i>in untuk melakukan
Seringnya pergantian pengembang /onsep praktek lokasiFolatilitas tinggi dari re:uirement,
teknologi, dan pengetahuan
Pengembangan a%al singkat, iterasi
pendekFolatilitas rendah Pengembangan a%al yang panjang
.. Permasalahan Projek Perangkat lunak yang besar
0erbeda dengan proyek perangkat lunak kecil, terdapat masalah industri yang
luas pada proyek perangkat lunak besar, yang diidentikasi dalam laporan yang
disebutkan sebelumnya. Menurut laporan ini, proyek perangkat lunak besar
dengan anggaran lebih dari G#H juta memiliki probabilitas keberhasilan rendah
#HB, dan 1IB dari mereka dibatalkan. &ngka"angka ini me%akili kerugian
nansial besar dan memalukan komunitas kami. Perhatikan proses ES,
didokumentasikan kisah sukses yang melibatkan proyek"proyek perangkat lunak
yang besar dan melibatkan iterative, directed, open source, inner source, ataucentrali>ed prosess6 ekstraksi dari pengalaman positif proyek"proyek ini dan
mempopulerkan adalah tujuan yang memaksa bagi para peneliti evolusi
perangkat lunak.
/ebingungan tentang terminologi mungkin menjadi faktor yang terlibat pada
keadaan ini. Sayangnya, banyak perdebatan tentang proses seleksi menjadi
dikotomi yang salah *%aterfall vs agile. Perdebatan ini mengabaikan berbagai
pilihan proses ES yang lain dan kesalahan penalaran ini tampak pada survey
dan diskusi industry.
Perdebatan tentang pilihan yang tersedia dapat menjadi factor yang terlibat
terhadap masalah pengembangan perangkat lunak besar. @erserah peneliti untuk
membingkai perdebatan ini, untuk memindahkan dari pilihan *%aterfall vs agile
7/26/2019 Rangkuman Software Evolution and Maintenance
http://slidepdf.com/reader/full/rangkuman-software-evolution-and-maintenance 6/17
untuk perdebatan yang lebih akurat yang memperhitungkan ketersediaan semua
proses ES.
apat dipertimbangkan *%aterfall dari perdebatan ini sebagai kata kode untuk
proyek dengan initial development yang besar dan evolusi tidak ada atau sangat
pendek. *&gile dalam konteks ini adalah kata kode untuk proyek"proyek dengan
initial development yang singkat diikuti oleh ES yang menggunakan setidaknya
beberapa praktek agile.
0anyak informasi dan perdebatan akan menimbulkan pertanyaan"pertanyaan
berikut'
" &pa ukuran yang tepat dari initial development untuk proyek iniJ" Setelah initial development, proses ES yang mana atau kombinasi yang
paling tepat untuk pengembangan lebih lanjut, mengingat keadaan proyek
iniJ
Pergeseran dalam perdebatan ini mungkin lebih memperjelas pilihan yang ada
dalam pemilihan proses pengembangan, dan membantu untuk menghindari
beberapa bencana.
1. Model fase perubahan perangkat lunak
S= adalah dasar dari semua proses evolusi perangkat lunak dan peran sentral
dalam pengembangan perangkat lunak ditegaskan oleh data survey. 0anyak
peneliti telah berurusan dengan berbagai aspek S=. 0eberapa model S= telah
diajukan, diantaranya *@est riven evelopment atau *5egacy =ode change
algorithm. Mereka adalah kasus khusus dari fase model lebih umum perubahan
perangkat lunak (PMS=) yang juga menggabungkan hasil penelitian terbaru.
1.#Case perubahan perangkat lunak
ambar . Model fase perubahan perangkat lunak (PMS=)
7/26/2019 Rangkuman Software Evolution and Maintenance
http://slidepdf.com/reader/full/rangkuman-software-evolution-and-maintenance 7/17
-nitiation phase memiliki persyaratan ' elisitasi, analisis, prioritas, dan
sebagainya.
=oncept location menemukan modul atau potongan kode yang harus diubah
untuk menerapkan perubahan.
-mpact analysis menentukan strategi dan perluasan perubahan.
&ctuali>ation mengimplementasikan fungsionalitas baru dan dimasukkan
kedalam kode lama. &ctuali>ation mungkin juga memerlukan propagasi yang
membuat perubahan sekunder dalam kode lama.
+efactoring merubah struktur perangkat lunak tanpa merubah fungsinya.
/etika dilakukan sebelum &ctuali>ation disebut prefactoring. Prefactoring
mempersiapkan kode lama untuk actuali>ation dan memberikan struktur
yang akan membuat actuali>ation lebih mudah. Sebagai contoh, prefactoring
dapat mengumpulkan semua potongan"potongan fungsi yang akan diubah
dan membuat actuali>ation local, sehingga mempengaruhi modul perangkat
lunak yang lebih sedikit. Postfactoring melakukan clean"up setelah
actuali>ation.
Ferication menjamin kualitas dari pekerjaan, dan disisipkan pada fase
prefactoring, actuali>ation, postfactoring, dan conclusion. Meskipun tidak ada
jumlah verication dapat memberikan jaminan lengkap kebenaran perangkat
lunak, banyaknya bugs, dan masalah dapat diidentikasi dan dikeluarkan
melalui verication sistematis.
=onclusion merupakan fase terakhir dari S=6 setelah kode baru selesai dan
diverikasi6 programmer berkomitmen kedalam versi sistem kontrol
repositori. =onclusion menciptakan dasar baru, update dokumentasi,persiapan rilis baru, dan lainnya.
1. *Sebagai kebutuhan Pemahaman program
Selama evolusi programmer harus memahami program yang sudah ada
untuk dapat menambahkan fungsi baru atau properti baru. Perangkat lunak
yang sudah ada kadang"kadang sangat besar dan pengembang
menggunakan pendekatan sebagai kebutuhan untuk berksontrasi hanya pada
bagian kode yang perlu dipahami. Mereka berprilaku seperti turis yang
mengunjungi kota besar seperti Praha, dan yang juga secara naluriah
pendekatan yang dibutuhkan, tetap mereka tidak memperhatikan seluruh
kota dan segala kompleksitasnya.
Sebuah teori yang menggaris ba%ahi pemahaman yang dibutuhkan diadopsi
dari ilmu 0ahasa dan matematika. /onsep adalah gagasan dasar dari teori ini
dan mengikuti karya Crege dan de Saussure, setiap konsep memiliki tiga
atribut yaitu name, intension, dan e;tension.
7/26/2019 Rangkuman Software Evolution and Maintenance
http://slidepdf.com/reader/full/rangkuman-software-evolution-and-maintenance 8/17
ambar 1. /onsep @ riangle
Dama adalah label yang mengidentikasi konsep, intension menjelaskan
makna dari konsep, dan e;tension segala sesuatu yang menjelaskan konsep,
termasuk potongan kode yang mengimplementasikan konsep. Enam proses
pemahaman berbasis konsep '
" 5ocation ' intension K e;tension" +ecognition ' e;tension K intension" Daming ' intension K name" enition ' name K intension" &nnotation ' e;tension K name" @raceability ' name K e;tension
Proses ini berperan sebagai kebutuhan pemahaman program. =oncept
location penting karena merupakan fase PMS=. -ni merupakan kemajuan
dalam pemahaman yang dibutuhkan untuk mengisi bagian akhir yang hilang
dari pu>>le dan memungkinkan pembuatan MS= terintegrasi.
1..# =oncept 5ocation
=oncept 5ocation adalah pencarian ekstensi konsep dalam kode. /onsep
pengembang mencari kebiasaan bersumber dari permintaan perubahan.
=oncept location dapat menjadi tugas kecil dalam program kecil, tetapi dapat
menjadi tugas dalam program besar atau asing. /etika dilakukan dalam
program besar, menyerupai permintaan internet6 Damun hal itu dilakukan
dalam kode dan atau produk kerja perangkat lunak lain. =oncept location
biasanya merupakan langkah a%al dari perubahan perangkat lunak, dan
perannya adalah untuk menemukan potongan kode yang
mengimplementasikan ekstensi dari konsep. Modikasi kode kemudian mulaidalam ekstensi konsep.
Programmer yang mengetahui kode mereka dengan sempurna dapa
menemukan ekstensi konsep dengan cepat, tetapi pendekatan ini gagal
dalam program besar atau tidak diketahui. -dealnya, dalam situasi ini, harus
ada dokumentasi eksternal yang menyediakan traceability, yaitu memandu
programmer dari konsep name ke tempat yang tepat pada kode. Damun,
dokumentasi tersebut sangat langka. Programmer tradisional menggunakan
pencocokan pola string dengan *grep yang menempatkan identier atau
komentar yang menunjukkan adanya ekstensi konsep dalam kode.
7/26/2019 Rangkuman Software Evolution and Maintenance
http://slidepdf.com/reader/full/rangkuman-software-evolution-and-maintenance 9/17
rep memiliki keterbatasan. -ni sering gagal karena penggunaan sinonim
atau homonim dengan presisi rendah dan mengingat kueri grep. Pencarian
untuk teknik concept location yang lebih baik adalah masalah penting dalam
perangkat lunak pada penelitian evolusi. @eknik concept location baru secara
luas jatuh ke dalam kategori statis dan dinamis. @eknik statis menganalisa
kode sumber perangkat lunak atau dokumentasi. @eknik dinamis manganalisahasil dari eksekusi program.
Salah satu perangkat tambahan adalah perluasan dari concept location diluar
pencarian untuk konsep tunggal. Peta konsep terdiri dari beberapa konsep
terkait, dan ada bukti bah%a konsep yang terkait dalam peta konsep
kemungkinan akan terkait dalam kode. ?leh karena itu, menemukan setiap
konsep terkait akan mengarah ke lokasi kode dimana modikasi kode dapat
dimulai.
1.. impact anlysis
-mpact analysis memperluas hasil concept location dan menentukanperubahan sepenuhnya dengan mencari semua komponen perangkat lunak
yang akan terpengaruh oleh perubahan perangkat lunak. -ni adalah tahap
prencanaan yang menentukan strategi perubahan dan juga merupakan
bagian dari pemahan program yang dibutuhkan. Damun secara metodologi
sangat berbeda dari concept location yang dijelaskan sebelumnya dan itu
merupakan topik penelitian yang terpisah.
Salah satu praktek relevan adalah impact analysis inkremental yang
menggunakan langkah demi langkah navigasi program dependen. Lika
komponen = dijad%alkan akan dimodikasi, pengembang memeriksa semua
komponen yang berinteraksi dengan = melalui dependensi dan memutuskanmana yang harus diubah dan mana yang tidak. Proses berulang sampai
semua komponen yang berinterkasi dengan komponen modikasi. L+ipples
adalah alat yang mendukung proses ini.
1.1&rah masa depan perubahan perangkat lunak
Perubahan perangkat lunak adalah seperti tugas fundamental dalam
rekayasa perangkat lunak, baik praktek terkait dan alat pentukung perlu
perbaikan terus menerus.
=oncept location menyajikan berbagai permasalahan, termasuk investigasi
concept location dalam dokumentasi eksternal, khususnya anotasi. =onceptlocation dapat ditingkatkan dengan praktek membuat dan memelihara
traceability link yang memberikan daftar concept name dan link ke concept
e;tension dalam kode. Luga penggunaan peta konsep domain ontology dalam
concept location adalah arah yang menjanjikan yang harus mendapatkan
perhatian lebih lanjut.
-mpact analysis adalah fase perencanaan yang membantu pengembang
dengan perencanaan S=. Damun sebagian besar penelitian terktini tentang
impact analysis menganggap hanya apakah modul berpengaruh atau tidak
dan perbedaan ini terlalu mentah untuk perencanaan6 modikasi modul
berkisar dari perbaikan lengkap untuk penyesuaian kecil dan impact analysis
harus mengukur kompleksitas dari dampak, karena dapat berperan dalam
memilih trategi untuk S=.
7/26/2019 Rangkuman Software Evolution and Maintenance
http://slidepdf.com/reader/full/rangkuman-software-evolution-and-maintenance 10/17
-mpact analysis inkremental didasarkan pada navigasi melalui dependensi
program6 beberapa dependensi menyebarkan perubahan sementara yang
lainnya tidak. 7ntuk membuat navigasi lebih mudah dikerjakan, heuristik dan
tools mengidentikasi *kemungkinan untuk menyebarkan dependensi perlu
perhatian lebih lanjut. /umpulan heuristik diperlukan untuk menentukan
kapan inpact anlysis inkremental selesai.
Pada studi kasus, impact analysis mampu memprediksi prefactoring dan
actuali>ation tetapi tidak dapat memprediksi postfactoring. ipercaya bah%a
postfactoring sering dilakukan secara reaktif dan postfactoring yang
membersihkan utang teknis kecil sering ditunda. !utang teknis sering
diselesaikan hanya ketika terakumulasi melampaui batas yang diterima.
Caktor ini yang membuat prediksi postfactoring sulit. Damun untuk
perencanaan yang lebih baik dari perubahan perangkat lunak, masalah ini
perlu penelitian lebih lanjut.
@erdapat kebutuhan untuk memuluskan lingkungan perangkat lunak yang
akan mendukung semua fase dari PMS= dan memantau kualitas kode yang
dihasilkan. Saat ini S= didukung beberapa teknologi. =ontohnya L+ipples,
sebuah plugin eclipse yang mendukung concept location, impact analysis,
dan perubahan propagasi. Mylyn membantu programmer dalam mengelola
alur kerja dan mengukur usaha. 7ntuk merekam dan mengekspor %aktu data
yang dibutuhkan plugin tambahan, @asktop. Pengujian unit yang dilakukan
oleh Lunit dan tes fungsional digunakan frame%ork pengujian &bbot Lava 7-.
Selain itu ada alat untuk mengukur ukuran kode dan ukuran perubahan kode,
dan alat pengukur cakupan pengujian. /etika menggunakan alat ini,
kurangnya integrasi alat adalah kendala utama. Sebuah lingkungan
perangkat lunak terpadu yang mengintegrasikan alat dan mendukung semua
kebutuhan S= adalah topik untuk pekerjaan masa depan.
$ Metode Penelitian
$.# Empirical ork
=ase studies adalah pengamatan dari satu atau beberapa fenomena. Sangat
sering, case studies menyediakan bukti dari fakta"fakta penting tentang
evolusi perangkat lunak dan membuka %a%asan baru dalam penelitian.
=ontrolled e;periments adalah proses empiris yang mengontrol variabel
independen dan mempelajari efeknya pada variabel dependen. i antara
mereka, eksperimen kerja menggunakan variabel independen yang me%akiliproduk kerja dari evolusi perangkat lunak, yang paling sering adalah kode.
Percobaan ini tidak melibatkan subjek manusia dan karenanya mudah untuk
dilakukan, namun tetap saja mereka dapat mengungkapkan pentingnya
pengamata empiris. Sebagai contoh, sebuah penelitian menemukan bah%a
easy"to"compute dan berskala *static e;ecution after hubungan seringkali
dapat menggantikan hard"to"compute tradisional mengiris dependensi,
dengan presisi kerugian yang kecil.
Softare repositori adalah produk kerja yang berisi banyak informasi tentang
evolusi perangkat lunak masa lalu. Pertambangan perangkat lunak repositori
merupakan area penelitian yang aktif dan menjanjikan.
7/26/2019 Rangkuman Software Evolution and Maintenance
http://slidepdf.com/reader/full/rangkuman-software-evolution-and-maintenance 11/17
Sebuah teknik empiris yang muncul tersedia untuk penelitian dari alat evolusi
perangkat lunak yang diusulkan dan teknik pemeragaannya. Pemeragaan
adalah proses dimana informasi tentang perubahan perangkat lunak lama
diekstrak dari repositori dan pengembang mengulangi perubahan terakhir
menggunakan alat dan teknik baru. !asil dari peragaaan menunjukkan
efektivitas dari alat"alat atau teknik baru. alam simulasi peragaaan, sebuahalgoritma mensimulasikan aksi dari pengembang manusia. Simulasi peragaan
secara umum merupakan penelitian dari impact analysis atau concept
location.
/elas lain dari eksperimen terkontrol melibatkan pengembang dan subjek
manusia lainnya. Penting dalam konteks ini adalah perbedaan antara pemula
dan ahli6 perbedaan besar antara dua kelompok ini telah didokumentasikan
dalam beberapa konteks.
Survei menggunakan kuisioner yang diisi penerima dan hasilnya ditabulasi
peneliti. @erdapat banyak survei yang berdampak pada cara kita memahami
evolusi perangkat lunak6 antara penemuan yang ditemukan yang telah
disebutkan sebelumnya dari masalah serius pada evolusi sistem perangkat
lunak besar. Survei dapat dilakukan ketika fenomena yang sedang diteliti
sudah tersebar luas dan terkenal, dan karenanya mereka bekerja pada akhir
yang berla%anan dari spectrum pada studi kasus.
ari gambaran singkat ini, jelas bah%a terdapat spektrum yang luas dari
teknik empiris dan pendekatan yang tersedia untuk peneliti dalam evolusi
perangkat lunak dan teknik ini membantu kita untuk menemukan keberadaan
evolusi perangkat lunak dan memperdalam pemahaman kita tentang hal itu.
$. Penalaran tentang EvolusiSementara pekerjaan empiris menemukan fakta dari evolusi perangkat lunak,
penalaran yang menggabungkan fakta ke dalam sebuah model (teori).
0erdasarkan model ini, peneliti merumuskan hipotesa, prediksi, dan
rekomendasi praktek. Lika model (teori) ini dipatahkan oleh fakta baru yang
diperoleh secara empiris, mereka harus diganti dengan yang lebih baik yang
mengakomodasi fakta"fakta baru. Pergantian dari pengamatan empiris dan
penciptaan model adalah dasar dari penemuan ilmiah dan juga telah
diterapkan di bidang evolusi perangkat lunak. Model evolusi perangkat lunak
sebagian besar informal6 Damun, mereka telah menjelaskan banyak aspek
dari evolusi perangkat lunak. Mereka meringkas pemahaman kita tentang
evolusi perangkat lunak dan mendukung penalaran kita tentang hal itu.
Sebagai contoh, model informal, Cred 0ooks mengidentikasi kesulitan
perangkat lunak sebagai kompleksitas, interoperabilitas, tembus pandang,
dan berubah"ubah, dan menggunakan mereka untuk memprediksi bah%a
pengembang peralatan perangkat lunak yang lebih baik akan menjadi lambat
dan sulit. @eori ini juga terbukti berguna dalam menjelaskan pergeseran
paradigma sebelumnya dalam rekayasa perangkat lunak. Pergeseran
paradigma pertama (#4H) disebabkan oleh kompleksitas perangkat lunak
dan mendorong menuju pemahaman yang lebih baik tentang cara bagaimana
untuk menghadapinya, termasuk komposisi perangkat lunak dari bagian
sederhana (modul), informasi tersembunyi, abstraksi, arsitektur, pola, dan
sebagainya. Pergeseran paradigm kedua (HHH) disebabkan oleh
7/26/2019 Rangkuman Software Evolution and Maintenance
http://slidepdf.com/reader/full/rangkuman-software-evolution-and-maintenance 12/17
interoperabilitas' Setiap perubahan domain perangkat lunak harus tercermin
dalam perubahan perangkat lunak yang sesuai, dan domain volatile
memerlukan perulangan perubahan perangkat lunak, yaitu evolusi perangkat
lunak. -tu memindahkan ES ke dalam arus utama pengembangan perangkat
lunak.
Staged model merupakan produk dari proses penemuan pengetahuan. Model
Sneed pada perangkat lunak lifespan terletak pada dasar pertama.
0erdasarkan hal itu, 5ehner mensurvei lifespan #1 sistem bisnis dari 7pper
&ustria dan menemukan perbedaan yang jelas antara perangkat lunak
*gro%th dan *saturation. engan demikian ia secara empiris membantah
pendapat sebelumnya bah%a evolusi dan pertumbuhan perangkat lunak terus
tanpa batas. ?leh karena itu staged model adalah hasil dari proses penemuan
pengetahuan yang terdiri dari langkah berikut '
Model K dara empiris K model baru
Proses serupa dari penemuan pengetahuan menyebabkan PMS= dan model(teori) lainnya yang membantu kita untuk memahami evolusi perangkat
lunak.
$.1 &rah masa depan dalam Metode Penelitian
$.1.# Empirical ork
0erbagai teknik empiris menyediakan berbagai tingkat kepercayaan dan
ancaman yang berbeda untuk validitas6 karena itu, sering tidak mungkin atau
tidak pantas untuk mengganti salah satu teknik orang lain. 0erbagai teknik
empiris diperlukan dan upaya untuk mempersempit pilihan yang tersedia
adalah tidak %ajar.
Sebagai fakta observasi penting, harus ada upaya lebih dikhususkan untuk
replikasiNperulangan. +eplikasi dapat menghapus beberapa ancaman
terhadap validitas dengan menggunakan teknik empiris yang berbeda dari
yang digunakan dalam studi asli. Sebagai contoh, sebuah studi yang
menggunakan peragaan simulasi dapat direplikasi oleh percobaan terkontrol
yang melibatkan pengembang manusia, atau sebaliknya. /ombinasi dari
metode empiris yang berbeda memiliki ancaman yang berbeda untuk
validitas sangat meningkatkan kepercayaan diri dalam hasil empiris.
$.1. Penalaran tentang Evolusi
Perhatikan bah%a menciptakan praktek rekomendasi berdasarkan hasil
empiris selalu membutuhkan penalaran dan tujuannya adalah untuk
membuat penalaran yang eksplisit, prakmatis dan suara. Perluasan @abel -
menjadi alat praktis yang dapat digunakan tidak hanya pengumpulan bukti
empiris, tetapi juga penalaran suara tentang bukti.
=ontoh penalaran yang salah dan konsekuensinya menggambarkan
mendesaknya tugas untuk mendapatkan penalarn tentang evolusi perangkat
lunak pada sound footing. Pekerjaan empiris tambahan hanya menyediakan
perlindungan kecil terhadap kesalahan penalaran6 sebaliknya, proses yang
lebih sistematis dalam penalaran evolusi perangkat lunak adalah perlu, dalamrangka meningkatkan proses penemuan pengetahuan. /omunitas harus
7/26/2019 Rangkuman Software Evolution and Maintenance
http://slidepdf.com/reader/full/rangkuman-software-evolution-and-maintenance 13/17
setuju apa yang merupakan alasan yang dapat diterima dan mengambil
langkah baru mencapai tujuan. Sebuah pendekatan yang sangat menjanjikan
mendukung untuk membuat model kecil untuk masalah tertentu. Pendekatan
inkremental ini memiliki peluang yang lebih baik dari keberhasilan model
besar yang mencoba untuk menjelaskan semuanya. 0erikut ini merupakan
daftar good model'
#. enisi dan asumsi yang merupakan model. 0ukti empiris yang mendukung model (pembenaran)1. Perdiksi yang berguna dan rekomendasi praktek dari model (penalaran)$. Prediksi yang sangat cocok untuk eksplorasi empiris kedepannya dan
dapat menguatkan atau menyalahkan model (falsiability)
=hecklist ini tidak dapat menjamin bah%a rekomendasi praktek selalu benar,
ini dapat meningkatkan *battling average dengan mengungkapkan denisi
yang membingungkan, pembenaran yang memadai, kesalahan dalam
penalaran, atau model yang kekurangan falsiability dan karenanya tidak
me%akili pengetahuan ilmiah.
2. Mengajar Evolusi Perangkat lunak
Perusahaan dan sekolah pascasarjana mengharapkan lulusan ilmu komputer
untuk dapat bekerja sebagai pengembang dalam proyek perangkat lunak.
Damun banyak program akademik menghilangkan tujuan pendidikan ini,
0jarne Stroustop mengamati ' banyak lulusan memiliki dasar tidak ada
pendidikan atau pelatihan dalam pengembangan perangkat lunak diluar
kegiatan hobi mereka. Seara khusus, banyak melihar pemrograman sebagai
upaya minimal untuk menyelesaikan pekerjaan rumah dan jarang melihat
pandangan yang lebih luas yang mencakup pengujian sistematis,
pemeliharaan, dikumentasi, dan penggunaan kode mereka oleh orang lain.
0agi banyak orang *pemrograman telah menjadi kombinasi yang aneh dari
unprincipal hacking dan memohon library orang lain.
Mengajar evolusi perangkat lunak membangun jembatan antara program
akademik dan lulusan, sebagai jumlah besar proyek perangkat lunak
menggunakan beberapa bentuk ES. @he rst perangkat lunak engineering
course (# SE=) dapat direorganisasi terhadap keterampilan evolusi perangkat
lunak. Damun reorganisasi membutuhkan banyak instruktur, sebagai
kesenjangan antara pendekatan tradisional dan harapan saat ini lebih luas
dari asumsi umumnya.
7ntuk menjelaskan reorganisasi ini, pembelajaran sis%a dapat digambarkan
sebagai sebuah proses dimana sis%a memperolah urutan keterampilan
tambahan yang dibangun diatas satu sama lain. /eterampilan pertama
adalah pengantar pemrograman yang memungkinkan sis%a untuk
mengembangkan program"program kecil dan memberikan mereka rasa
percaya diri dalam kemampuan pemrograman dasar mereka. alam
kurikulum saat ini, tingkat kompetensi dicapai dalam kursus pengantar
pemrograman.
5angkah selanjutnya adalah pengetahuan dari portofolio teknologi yang
digunakan dalam proyek"proyek yang realistis. @eknologi ini meliputi versi
7/26/2019 Rangkuman Software Evolution and Maintenance
http://slidepdf.com/reader/full/rangkuman-software-evolution-and-maintenance 14/17
sistem kontrol, 7- dan pengujian frame%ork, pemodelan, dan alat
monitoring, dan sebagainya.
5alu diikuti pelajaran dasar PMS= yang merupakan dasar dari semua proses
ES. PMS= adalah tujuan utama dari revisi #SE= dan hilang di banyak
kurikulum saat ini. #SE= terstruktur seperti ini membuka pintu untuk
mempelajari praktek lanjutan dari berbagai proses ES dan sisanya dari
disiplin rekayasa perangkat lunak. Lad%al semester dari #SE= pada ayne
State 7niversity disajikan pada @abel --.
@abel --. Lad%al semester perkuliahan
Mingg
u
@opik
# Silabus, sejarah rekayasa perangkat lunak Perangkat lunak life span model, teknologi1 Permulaan perubahan perangkat lunak
$ =oncept location2 -mpact analysis3 &ctuali>ation4 +efactoringI Ferication Ferication, lanjutan#H /esimpulan perubahan perangkat lunak, pengenalan proses
perangkat lunak## Evolusi pengembangan perangkat lunak# -nitial development#1 @ahap akhir perangkat lunak lifespan
#$ Etika professional
0elajar PMS= membutuhkan praktek pada proyek"proyek nyata yang
me%akili pengembangan perangkat lunak saat ini dan pada saat yang cocok
untuk memulai pengembangan. i ayne 7niversity, menggunakan proyek
open source yang dikembangkan di laboratorium yang berjalan secara pararel
dengan kuliah. Sis%a dibagi dalam tim dan setiap tim diberikan sebuah
proyek open source yang spesik. Setiap sis%a di dalam tim diberi
permintaan perubahan yang berbeda dan memiliki tenggat %aktu. -nstruktur
dan asisten pengajar mengelola proses ' mereka menetapkan permintaan
perubahan ke sis%a, membantu mereka untuk memecahkan konOik, dan
membantu untuk menciptakan baseline baru setelah tenggat %aktu.
Perubahan kode yang diperlukan adalah meningkatkan kompleksitas.
Perubahan pertama biasanya hanya membutuhkan concept location dan
modikasi kode minimal yang tidak merambat ke kelas lain. Perubahan kedua
sudah menyebar ke beberapa kelas dan mungkin melibatkan semua fase
PMS=. Perubahan ketiga biasanya melibatkan konOik dengan anggota tim
lainnya yang harus dipecahkan. Selama semester, mahasis%a biasanya
menulis sekitar 1HH baris kode yang harus sesuai dengan proyek yang ada
dan telah diuji secara menyeluruh, sehingga diharapkan kualitas kode. Lad%al
5ab disajikan pada @abel ---.
@abel --- Lad%a Semester 5ab
7/26/2019 Rangkuman Software Evolution and Maintenance
http://slidepdf.com/reader/full/rangkuman-software-evolution-and-maintenance 15/17
Mingg
u
@opik
# Silabus, alat proyek SFD, Merge dan i, iki1 @eknologi 7-' Q@, =make
$ Membagi kelas menjadi tim, menugaskan perubahan permintaan #2 +apat grup R tanya ja%ab tentang proyek3 Perubahan # R presentasi tim4 +efactoring < dalam latihan kelasI +apat grup R tanya ja%ab tentang proyek Perubahan R presentasi tim#H Pengujian unit < dalam latihan kelas## +apat grup R tanya ja%ab tentang proyek# +apat grup R tanya ja%ab tentang proyek#1 Perubahan 1 R presentasi tim#$ E;tra credit
Sedangkan, kelas di kuliah didasarkan pada ujian, nilai"nilai proyek sis%a
didasarkan pada kode yang dibuat sis%a dan kesesuaian laporan sis%a.
Melalui analisis versi data sistem kontrol, laporan sis%a, dan %a%ancara bila
diperlukan, instruktur dapat menilai tanggung ja%ab individu dan
mengidentikasi anggota tim yang menyebabkan masalah.
2.# &rah kedepannya dalam pengajaran
-ntegrasi lingkungan perangkat lunak yang mendukung PMS= dan itu akan
meningkatkan tidak hanya praktik ES, tetapi juga meningkatkan pengajaran
seperti itu akan membimbing sis%a ketika mereka menerapkan perubahanperangkat lunak. !al ini juga dapat membantu dengan monitoring dan grading.
L+ipples mendukung concept location dengan ketergantungan pencarian, impact
analysis, dan perubahan propagasi, tetapi dukungan untuk fase tambahan dan
alat"alat tambahan yang memberikan umpan balik juga dikehendaki.
&rah lain adalah untuk mengembangkan program yang membangun # SE= dan
mengajar topik yang lebih lanjut, misalnya peran lainnya dalam proses ES,
termasuk penguji, manajer, dan sebagainya.
PMS= dan fase individu masih diselidiki dan pengalaman tambahan sedang
dikumpulkan. &lat"alat baru dan teknik yang meningkatkan produktivitas atau
kualitas perubahan perangkat lunak harus dimasukkan kedalam #SE= di masadepan.
3. Pemeliharaan Perangkat lunak
Perangkat lunak memasuki tahap pemeliharaan ketika sudah ditransfer ke
pengguna. Sesuai dengan standar -S?N-E= #H4, *@ujuan dari proses
pemeliharaan perangkat lunak adalah untuk memberikan dukungan cost"
eective untuk produk perangkat lunak yang dikirimkan. Sementara banyak
penulis menyebut tahap pera%atan perangkat lunak, sebagai layanan perangkat
lunak.
Seperti evolusi perangkat lunak, pemeliharaan juga terdiri dari perulanganperubahan untuk perangkat lunak, tetapi tujuan berkurang drastis ' Satu"satunya
7/26/2019 Rangkuman Software Evolution and Maintenance
http://slidepdf.com/reader/full/rangkuman-software-evolution-and-maintenance 16/17
tujuannya adalah untuk menjaga perangkat lunak dapat digunakan dalam cara
yang hemat biaya, dan tidak ada lagi aspirasi untuk menambahkan tur baru
atau fungsionalitas. Perubahan bah%a melakukan tahap ini untuk mengkoreksi
(memperbaiki bug) atau adaptasi (beradaptasi dengan perubahan teknologi atau
penggunaan).
0anyak isu"isu spesik untuk pera%atan perangkat lunak bersumber dari fakta
bah%a perangkat lunak digunakn saat sedang dipelihara, dan bah%a tim yang
berbeda dari tim pengembang asli mungkin memelihara perangkat lunak.
Selama pemeliharaan, sangat umum setidaknya ada dua versi dari perangkat
lunak ' satu adalah versi yang diproduksi dan dipelihara (dilayani), sedangkan
secara pararel tim pengembang merubah versi lain untuk dirilis mendatang6
Situasi ini dijelaskan oleh versi model perangkat lunak lifespan.
!al yang penting adalah akhir dari evolusi perangkat lunak. Evolusi perangkat
lunak adalah proses yang mahal dan manajer dapat memutuskan bah%a mereka
tidak lagi ingin berinvestasi di dalamnya. /emudian berakhir dengan keputusan
manajemen sementara pemeliharaan dapat terus berlanjut selama perangkat
lunak digunakan.
Stabilisasi adalah situasi dimana evolusi perangkat lunak tidak lagi diperlukan.
&lasan yang disebutkan sebelumnya untuk evolusi perangkat lunak adalah
persyaratan volatilitas, teknologi, atau pengetahuan stakeholder. Setelah
volatilitas berhenti, proyek perangkat lunak mencapai stabilitas.
Stabilitas sering terjadi di embedded system yang mengontrol mekanisme
tertentu ' Setelah mekanisme diproduksi, itu tidak berubah dan oleh karena itu
kebutuhan perangkat lunak menjadi stabil. Sistem dilengkapi dengan chip
khusus dan sistem operasi tertentu dan teknologi ini juga stabil. Satu"satunyaalasan bagi evolusi adalah volatilitas dari pengetahuan stakeholder, di mana
stakeholder mepelajari bagaimana mengontrol mekanisme ini. Setelah
stakeholder menyelesaikan pembelajaran dan menemukan solusi, tidak ada
alasan untuk evolusi lebih lanjut dan perangkat lunak mencapai titik stabilitas.
Damun servis masih mungkin diperlukan.
=ode decay adalah alasan yang dapat menyebabkan akhir dari evolusi. Meskipun
perangkat lunak tidak material dan tidak tunduk pada keausan, struktur ini
meluruh di ba%ah pengaruh perubahan perangkat lunak. ejala"gejala code
decay meningkatkan kesulitan membuat perubahan perangkat lunak dan
penurunan kualitas kode, terutama peningkatan kehadiran bug. Situasi bisa
mencapai titik dimana evolusi lebih lanjut adalah diluar kemampuan tim
programmer.
/emampuan pengembang yang tidak memadai adalah salah satu alasan code
decay. 7ntuk memahami sistem, pengembang harus mengerti domain dari
aplikasi, arsitektur, algoritma, struktur data, ekstensi konsep dalam kode, dan
sebagainya. Lika pengetahuan tidak tersedia, kode baru yang dihasilkan tidak
cocok dengan kode lama dan perubahan perangkat lunak memperburuk code
decay. 0ahkan refactoring membutuhkan pengetahuan mendalam tentang
perangkat lunak dan tanpa itu, tidak mungkin dan sistem mengalami kerusakan
lebih lanjut. Sebagai gejala perkembang biakan kebusukan, kode menjadi lebih
dan lebih rumit dan pengetahuan yang diperlukan untuk evolusi justru
meningkat. /etika kesenjangan antara pengetahuan tim dan pertumbuhan
7/26/2019 Rangkuman Software Evolution and Maintenance
http://slidepdf.com/reader/full/rangkuman-software-evolution-and-maintenance 17/17
kompleksitas dari perangkat lunak terlalu besar, evolusi perangkat lunak menjadi
hilang.
=ontoh khusus dari hilangnya pengetahuan adalah pergeseran budaya.
+ekayasa perangkat lunak memiliki lebih dari setengah abad sejarah dan ada
program masih digunakan yang dibuat setengah abad lalu. Program ini
diciptakan dalam sifat yang sama sekali berbeda dari hard%are6 komputer yang
lambat dan memiliki lebih sedikit memori, sering membutuhkan algoritma yang
rumit. Selain itu programmer menulis dalam 0ahasa usang dan untuk sistem
operasi usang, dan pendapat"pendapat yang berbeda tentang apa yang
merupakan struktur yang baik dari perangkat lunak. Programmer saat ini
mencoba untuk mengubah program lama menghadapi masalah ganda ' mereka
harus memulihkan pengetahuan yang diperlukan untuk program tertentu, tetapi
mereka juga harus memulihkan budaya dimana program ini diciptakan. @anpa
itu, mereka mungkin tidak dapat membuat evolusi perubahan program.
3.# &rah kedepannya Pemeliharaan Perangkat lunak
&khir dari evolusi perangkat lunak adalah peristi%a yang sangat penting dan
dengan demikian layak menjadi studi berkelanjutan. =ode decay atau penuaan
perangkat lunak adalah masalah yang sangat serius ' teknik untuk menghindari
code decay dan evolusi perangkat lunak pantas menjadi penelitian
berkelanjutan. Pendekatan yang saling melengkapi adalah penelitian dari teknik
dan alat"alat yang memungkinkan penambahan fungsi baru untuk pembusukan
kode, dan melalui itu untuk memperpanjang evolusi perangkat lunak untuk kode
yang saat ini dianggap tidak bisa berevolusi.