Rangkuman Software Evolution and Maintenance

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 #.



-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.



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.



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



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



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=)



-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.



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.



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=.



-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.



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



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



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



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



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



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



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.

Rangkuman Software Evolution and Maintenance

Documents

Transcript of Rangkuman Software Evolution and Maintenance