MANAJEMEN PEMELIHARAAN DAN
KONFIGURASISOFTWARE
MANAJEMENPEMELIHARAAN DAN KONFIGURASI SOFTWARE IEEE Standard Glossary Software Engineering Tenninology mendefmisikan software maintenance (pemeliharaan software) sebagai modifIkasi produk software setelah ia dikeluarkan, untuk mengoreksi kesalahan, untuk meningkatkan penampilan atau atribut lainnya, atau untuk menyesuaikan produk dengan lingkungan yang telah berubah. Maintainability (daya pemeliharaan) akan dijelaskan pada Boo 1, disertai dengan penjelasan mengenai earn pengoreksian, pengubahan, dan peningkatan sistem software. Dengan demikian, pemeliharaan software dapat didefmisikan sebagai eara membuat dan mengelola perubahan software. Bagian pertama dari boo ini membahas masalah pemeliharaan software, biaya dan faktor biaya pemeliharaan, beberapa reneana yang telah dibuat untuk meningkatkan pemeliharaan dan peralatan yang digunakan untuk pemeliharaan dalam lingkungan UNIX. Bagian kedua membahas masalah pentingnya masalah mengenai life cycle, namun khususnya bagi kepentingan fae pengelolaan. Masalah manajemen konfigurasi software ini dapat digaris bawahi menjadi sebuah pertanyaan: Bagaimana perubahan yang tetap terhadap semua produk kerja proyek software dapat dimonitor, dikontrol, dan dikoordinir untuk menghasilkan suatu set produk kerja software yang konsisten dan menghasilkan release yang tepat untuk dikirimkan kepada pezanggan? Pembahasan kita mengenai' manajemen konfigurasi menitikberatkan pada penggunaan peralatan UNIX yang membantu memecahkan persoalan ini.
9. 1 PEMELIHARAAN SOFTWARE Lientz dan Swanson telah menemukan tiga jenis perubahan yang terjadi pada sistem selarna pemeliharaan, dan mereka telah mengadakan survai t~rhadap 487 pusat pemroses~ data bisnis mengenai usaha yang telah dilakukan oleh masing-masing pusat tersebut. Perfective maintenance (pemeliharaan perfektif) adalah aktivitas penambahan fungsi pada sistem, yang biasanya dalam usaha merespon (menanggapi) pennintaan dari para pemakai atau programmer. Lientz dan Swanson memperoleh kesimpulan
194
bOOwa pemeliharaan perfektif terdiri atas 51,3 persen dari usOOa pemeliharaan keseluruhan, dalam sampel mereka. Adapative maintenance (pemeliharaan adaptif) adalOOaktivitas pengubOOansistem karena untuk menyesuaikan dengan lingkungan operasi sistem. Sebagai contoh, bergantinyaprogram dari komputeryang menjalankan sistem operasi UNIX menjadi mekrikomputer yang menjalankan DOS. Ini adalOOcontoh pemeliharaan adaptif. Lientz dan Swanson mendapatkan kesimpulan bOOwapemeliharaan adaptif menduduki bagian sebanyak 23,6 persen dari usOOapemeliharaan. Corrective maintenance (pemeliharaan korektif), yaitu aktivitas untuk memperbaiki kesalOOansistem. Ia mempunyai porsi sebesar 21,7 persen dari usOOapemeliharaan. Bagi~ 3,4 persen dari usOOapemeliharaan ini digunakan untuk usOOa-usOOadalam bentuk lain. Namun dernikian, Arnold dan Parker memperoleh gambaran lain yang tidak sama dengan apa yang telOOdikemukakan oleh Lientz dan Swanson. Dengan menggunakan teknik analisa yang lebih cermat, mereka mendapatkan kesimpulan bOOwausOOapeningkatan kesempurnaan fungsi menduduki bagian 38 persen dari keseluruhan aktivitas pemeliharaan, perbaikan kesalOOanpunya porsi sebesar 36 persen, dan aktivitas lain, seperti bad data dan masalOOhardware punya porsi 26 persen. Gambaran ini digunakan untuk perencanan delapan tOOun dari data pemeliharaan NASA. .
KesimpulanLientz dan Swanson memberi pengertian bOOwapada dasarnya
aktivitas pemeliharaan bukanlOO perbaikan sistem, seperti yang telOO menjadi pendapat umum, namun aktivitas pemeliharaan. adalOOpenambOOan daya fungsi ke program. Data Arnold dan Parker juga menunjukkan bahwa aktivitas pemeliharaan yang paling penting adalOOpeningkatan program, walaupun barn pada tingkat rendOO.PerubOOan macam ini dapat lebih menjangkau modifIkasi persyaratan yang dikehendaki, disain, implementasi, dan dokum,entasi pemakai, dan akan lebih membutuhkan pengujian kembali yang ekstensif. Pemeliharaan perfektif membutuhkan life cycle penuh dari dirinya sendiri untuk melakukan perubOOan yang begitu tajam.
9.1.1 Biaya dan Faktor Biaya Pemeliharaan Fase pemeliharaan life cycle umumnya merupakan bagian termOOaldari suatu proyek, seringkali memakan biaya sebesar 50 persen atau lebih dari keseluruhan biaya pengembangandan pemeliharaan software. Menurut laporan Boehm, rasio biaya pemeliharaandibandingpengembanganadalOO40 banding 1. Menurut gambaran ini, sistem yang membutuhkan biaya pengembangan $1.000.000, akan membutuhkan biaya pemeliharaan sebesar $4.000.000. Banyak faktor, baik teknis maupun non-teknis, yang mempengarnhi biaya 195
pemeliharaan sistem. Beberapa faktor non-teknis tersebut meliputi: 1.
Tingkat kebaruan dan kompleksitas aplikasi yang diberikan. Proyek dengan komponen riset yang besar, rnisalnya,biasanya menghasilkan program yang selalu membutuhkan perubahan dibandingkan dengan proyek yang menggunakan teknologi yang telah.mapan.
2.
Stabilitas star. Jika programmer yang membuat kode yang memeliharanya, maka biaya pemeliharaanakan menjadi murah sebab untuk mempelajaridan memaharni bagian pemeliharaan tersebut akan lebih mudah.
3.
Masa berlakunya program. Lebih lama suatu sistem berlaku, maka ia akan membutuhkan perubahan dirinya dan lingkungan operasinya dengan lebih banyak.Disampingbiayapemeliharaanperfektifdan adaptif,biaya korektifnya juga akan lebihtinggi pada program yang lebih lama, sebab program tersebut telah tnengalami kerusakan. Program lama yang telah digunakan dan diubah-ubahselarnabertahun-tahunakhimyaakan sulitdisusundan dimengerti lagi, sehingga ia hampir tidak dapat diperbaiki.
4.
Ketergantungan program pada lingkungan eksternal. Pogram perpajakan mungkinmembutuhkanperubahanyang lebihsering,sebabadanyaperubahan rutin dalam peraturan perpajakan, tidak seperti pada program yang hanya diperlukan untuk menganalisa data produksi, rnisalnya.
Beberapa faktor teknis yang mempengaruhi biaya pemeliharan, meliputi berikut ini:
196
1.
Ketidaktergantungan modul. Sistem akan lebih mudah dipeliharajika salah satu bagian dapat diubah tanpa mempengaruhi bagian yang lainnya.
2.
Bahasa pemrograman. Program yang ditulis dengan bahasa pemrograman tingkat tinggi, seperti Pascal, biasanya lebih mudah pemeliharaannya dari pada program yang ditulis dalam bahaia tingkat rendah, seperti assembler. C adalah pertengahan antara dua tingkat ini.
3.
Validasi dan pengujian program. Penggunaanteknik validasidan pengujian yang tepat sepertiyang dibahaspada booterakhir,dapat meningkatkankualitas dan mengurangi biaya pemeliharaan korektif.
4.
Kualitas dokumentasi. Kebenaran,kelengkapan,dan kemampuandaya baca baik dari pemakai maupun dokumen teknik dapat mengurangi biaya pemaeiharaan.
Mengapa pemeliharaan memerlukan bagian yang besardari sumber-sumber proyek? Beberapa penjelasan akan dikemukakan dalam literatur ini. Salah satu alasannya adalah bahwa kebanyakan software dibuat dengan tidak baik. Banyak program yang ditulisl dibuat sebelum adanya metode disain dan pemrograman terstruktur yang efektif. Beberapa program terbuat dengan buruk sebab pembuatnya tidak terlatih dengan baik, atau ia tidak memiliki sumber-sumber yang memadai. Alasan lain mengapa biaya pemeliharaan tinggi adalah bahwa sulit untuk menentukan cara mengubah salah satu bagian sistem software yang bisa mempengaruhi bagian lain sistem tersebut. nggunaan modulariti dan disain interface yang baik merupakan cara terbaik untuk mengatasi masalah ini. Sumber penyebab lain mengenai tingginya biaya adalah bahwa software seringkali tidak didisain untuk pemeliharaan. Yaitu, masalah pemeliharaan tidak dipertimbangkan dalam keseluruhan life cycle, namun hanya pada waktu terakhir life cycle tersebut. Jika hal ini terjadi, maka akan terjadi pilihan disain yang jelek, sistem akan terdokumentasi dengan tidak tepat, akan terjadi ketergantungan pada lingkungan operasi tertentu, dan sebagainya. AI~an umum yang biasanya terjadi (seperti yang kita alarni) mengenai tingginya biaya pemeliharaan adalah gagalnya membuat dan mendokumentasikan perubahan secara lengkap. Seringkali dibuat perbaikan yang cepat untuk mengkode tanpa ada perubahan paralel yang diberi komentar, tanpa dokumen teknik seperti persyaratan dan dokumen disain, dan tanpa dokumen pemakai seperti manual referensi. Mengadakan perubahan yang sembarangan seperti ini akan mengakibatkan bertambahnya biaya dalam putilran aktivitas pemeliharaan selanjutnya, yaitu akan diperlukan banyak usaha untuk menemukan dan mendokumentasikan cara kerja program yang sesungguhnya, ~ebelum melakukan perubahan lebih lanjut. Dan hal ini akan mengakibatkan permasalahan tambah buruk. Alasan terakhir mengenai tingginya biaya pemeliharaan adalah tidak cukupnya sumber-sumber yang mungkin dibutuhkan dalam tugas pemeliharaan. Tugas .
pemeliharaan seringkali diserahkan kepada programmer yunior yang tidak mempunyai keterampilan dan pengalaman yang memadai untuk melakukannya. Aktivitas pemeliharaan seringkali diabaikan dalam anggaran biaya dan dilakukan dengan sembarangan, sehingga mengakibatkan macam perubahan yang tidak baik seperti yang telah dikemukakan di atas.
9.1.2 Penurunan Biaya perawatan Hal-hal apakah yang diperlukan untuk menghadapi masalah perawatan? Masalah yang cenderungmunculadalahtingginyabiaya perawatan,sepertisulitnya 197
meramalkan akibat-akibat dari suatu perubahan. Akan tetapi masih banyak pula masalah lainnya. Pertama kali, latihan-latihan harus selalu ditingkatkan. Praktek-praktek Rekayasa Perangkat Lunak tidak selalu digunakan pada proyek software. Para ahli softwarehams memepelajarilebih banyak lagi tentang piranti, teknik dan metode terbaik yang dapat dipilih disertai kedisiplinan dan pemakaiannya. Banyak dari teknik-teknik yang kita bahas sebelumnya, seperti desain moduler, kemudahan baca program yang tinggi, dan pemakaian inspeksi software serta metode tes regresi, semuanya dapat meningkatkan kemudahan perawatan sistem. Kedua, kebijaksanaan manajemen harus ditingkatkan. Perawatan hams ditentukan sehingga menjadi sumber yang memadai, kebijaksanaan personnel yang lebih baik, sepertimengadakanpenggiliranpara pekerja antara tugas desain, test, dan perawatan hams diciptakan. Kegiatan perawatan hams dipantau dan diukur. Penignkatan lain dapat berasal dari penelitian dan pengembanganyang terus menerus. Metode yang lebih baik, seperti evaluasi desain untuk menemukan kompleksitasnya, dapat mengarahkan pada desain yang lebih baik disamping membuat sistem akan lebihmudah perawatannya.Piranti-pirantiyang ditingkatkan yang digunakan untuk mendukung kegiatan perawatan dapat meningkatkan produktivitas perawatan.
9.1.3 Piranti UNIX untuk Perawatan Pertama kali yang hams diketahui oleh seorang pakar software dalam perawatan adalah tentang cara kerja sistem. Untuk memaharni kode orang lain merupakan pekerjaan yang tidak mudah. Bila mempertimbangkan' betapa banyaknya sistemyang mernilikidesain sertakodeyangburuk, maka dapat dikatan bahwa hampir tidak mungkin untuk mel
bahwa perubahan telah dilakukan dengan benar. Dalam masing-masing kategori terdapat daftar piranti UNIX (bila ada) yang sesuai dengan kategori tersebut.
.
Piranti yang membantupetugasperawatandalam melihatstrukturdalam kode pada saat meneoba memahaminya. Struktur tingkat yang paling tinggi pada sistem software C adalah pada tingkat modul kompile dan file header. Modul kompile C dan file header merupakanm file UNIX yang berisikan kode sumber C. Utilitas make merupakan alat utama untuk menentukan struktur sistem pada tingkat ini. makefile pada sistem dapat memberi tahu programmer perawatan baik tentang kode yang menyusun sistem serta tentang bagaiman file ini saling ketergantungan. Struktur pada tingkat yang lebih rendah merupakan urutan pemanggilan dan hirarki fungsi C. Hirarki pemanggilan fungsi yang menyerupai laporan ct1ow, cscope, dan cia, misalnya, merupakan bagian informasi tentang sistem.
Alur kontrol merupakan tipe struktur lainnya. Alur ini dapat dilaeak dengan fungsi tahap dalam debugger simbolik seperti sdb, dan dbx, serta dengan piranti seperti ctrace. Debugger simbolik dan ctrace dapat membantu menentukan earn pengirimandata diantaramodul sistemdan fungsi dalam sistem tersebut.
.
Pirantiyangmembantuprogrammermenemukandataumumyangditunjuk oleh nama variabel yang berbeda. Pemakaian pointer yang luas dalam banyak program C membuat tugas ini menjadi penting dan sulit. Namun sayangnya tidak terdapat piranti UNIX/C yang tersedia seeara umum untuk membantu tugas ini.
.
Pirantiuntuk menyusunstrukturkode kembali.cb membantudalam menyusun struktur kembali kode sumber sehingga mudah dibaca. Namun tidak terdapat piranti untuk membuat struktur program logis kembali yang tersedia secara umum untuk C.
.
Piranti untuk menyimpankasus test dan mengujioutput test. Sistemfile UNIX dapat dipakaiuntuk menyimpankasus test, dan skrip shell UNIX 199
dapat ditulis untuk mengotomatisasi proses pengujian. ditJ dapat dipakai untuk membandingkanoutput program dengan output yang diharapkan. Meskipun sistem UNIX menawarkan banyak piranti untuk membantu programmer perawatan C, namun hanya terdapatbeberapa kategori dalam daftar ini yang efisien, dan beberapa kategori dimana piranti yang lebih baik akan bermanfaat.
9.2 MANAJEMENKONFIGURASISOFTWARE Proyek pengembangiill software menghasilkan dokumen pengembangan, kode, kasus test, dokumen pernakai dan sebagainya. Materi ini berubah dalam seluruh tahap-tahap pengembangan. Produk kerja memiliki versi yang berurutan, dengan versi dimana satu item sesuai dengan berbagai versi pada item lainnya. Sebagai contoh, penanganan utama selama tahap perawatan mungkin memerlukan dokumen persyaratan baru, yang kemudian mengarah pada desai yang baru, kode yang diubah, kasus test baru atau yang talah direvisi, dan sebagainya. Akhirnya keluaran baru produk software dihasilkan. Versi baru dari dokumen -kode, kasus terst, dan sebagainya- biasanya tidak sesuai dengan versi lama. Versi lama harus dapat dibetulkan sehingg~ mereka dapat dipakai untuk membetulkan kesalahan, menjawab pertanyaa, atau membuat perbaikan terhadap keluaran sebelumnya, dan sebagainya. Dalam proyek menengah sekalipun dengan beberapa orang yang membuat perubahan produk kerja, maka kekacauan dapat segera mundul. Dalam manajemen konfigurasi software, seseorang memantau dan mengendalikan perubahan pada produk kerja software. Dia juga mengkoordinasikan produk kerja untuk menghasilkan keluaran produk yang konsisten dan benar. Meskipun kita membahas masalah ini dengan tahap perawatan, manajemen konfigurasi software merupakan kegiatan yang penting dalam tahap-tahap pengembangan sistem. Kita membagi ~anajemen konfugarsi ke dalam tiga kegiatan sebagai berikut:
.
200
Kontrol Versi. Bila produk kerja software berubah, rnaka produk tersebut telah membentuk versi yang berikutnya. Kontrol versi merupakan aktifitas pengawasan terhadap versi-versi ini.
.
Kontrol Pembahan. Kontrolperbuhanadalahproseduruntukpennintaan perubahan,penentuanapakahperubahanhams dibuat,pembuatanperubahan, menyimpan dang menguji perubahan.
.
Kontrol Pembuatan. Mengawasidan rnencatatversi-versiproduk.kerja yang berlangsung untuk membuat suatu release, dan rnembuat produk kerja yang dikirim dengan benar. Semua kegiatan ini disebut kontrol pembuatan.
Kita membahas rnasing-masing komponen diatas satu persatu.
9.2.1. KONTROL VERSI Item konfigurasi software atau item, adalah semua produk kerja ptoyek software yang diperlakukansebagai satu unit untuk kontrol versi. Contoh-contoh item mencakuppersyaratandan dokumendesain,kumpulankasus test, file header, dan dokumen pemakai. Item sering diubah untuk menghasilkan varian. Kadang-kadang varian dibedakan dengan versi untuk disimpan sebagai catatan sistem kontrol versi. Versi pertarna dari suatu item disebut baseline. Sebagai contoh, dokumen desain dapat mernilikibaseline pada tahap desain. Versi kedua dapat dibuat selarna tahap pengkodean, versi ketiga dibuat untuk release kedua dari produk tersebut dan sebagainya. Kecualiuntukbaseline versi selaludibuat denganmengubahversi berikutnya., y~g disebut versi pendahulu ( predecessor ). Umurnnya suatu versi dikatakan sebagai versi penerus pendahulunya. Kita dapat membedakan dua jenis versi : satu versi merupakan revisi apabila versi ini merupakanpengganti dari versi lain. Satu versi merupakan variasi, atau cabang apabila versi ini merupakan satu dari beberapa versi altematif. Satu variasi dapat dibuat dari versi lain atau suatu baseline. Revisi dibuat karena selalu diperlukan untuk membetuIkankesalahan, mengganti dan menarnbahkaninforrnasi dan sebagainya. Variasi dibuat karena adanya kebutuhan untuk membuat sistem dalarn lingkungandan pemakaian yang berbeda. Sebagai garnbaran; rnisalnya bahwa suatu dokumen persyaratan baseline diubah untuk membetuIkanbeberapa kesalahan. Versi yang bam ini merupakan revisi dari baseline tersebut, karena versi ini dimaksudkansebagai penggantinya. Sekarang rnisalnya dua dokumen persyaratan tarnbahan dibuat dari versi yang telah dibetuIkandengan menjelaskandua produk yang sedikit berbeda untuk dua pasar yang bam. Oleh karenaketigadokumenpersyaratanini merupakanaltematif, yang tidak dirnaksudkan sebagai pengganti lainnya.,maka mereka rnerupakan variasi, bukan revisi. Dalarn proyek-proyek yang besar yang membuat release 201
----
--
jarnak atau variasi yang banyak dari release tersebut untuk pasar atau lingkungan operasi yang berbeda, mungkin banyak variasi dan revisi untuk semua item. Sistem kontrol versi harns mengawasi dan mencatat semua versi dan item yang mencakup informasi pendahulu dan penerus. Kontrol versi khususnya merupakan fungsi sistem data base, atau fungsi penyimpanan record. Pada proyek-proyek yang keeil dengan beberapa orang bidang pengembangan, sistem kertas yang informal mungkin dapat memenuhi persyaratan; namun biasanya tugas ini cukup kompleks dan besar, yang memerlukan piranti-piranti mesin seperti Source Code Control Sistem (SCCS) atau Revision Control Sistem (RCS). Piranti-piranti ini memiliki fungsi yang hampir sarna. Kita membahas SCCS untuk tujuan illustrasi. SCCS merupakn piranti centrol versi yang populer untuk item-item yang disimpan sebagai file UNIX. sees juga memberikan beberapa perubahan dan kemarnpuan kontrol pembuatan. Pelayanan sees :
.
.
.
Penyimpananversi.sees merekamperubahan-perubahan kedalarnfile-file dan membentuk versibarn. Dokumendan tanggal versi tentang versi tersebut ditulis. sees hanya menyimpan perubahan kedalarn file bukan file yang lengkap untuk masing-masing versi. Hal ini akan menghemat tempat penyimpanan dan memungkinkan sees untuk menyimpan berbagai versi hanya dalarn ruang yang sedikit lebih luas daripada yang diperlukan oleh satu versi. Perubahan ini dikenal dengan delta.
Pengambilanversi.sees semuafile.
memungkinkanpengarnbilansemua versi dari
Penggabungandan penghapusanversisees memungkinkanpenghapusan dan penggabunganversiuntukmembuatpohonversilebih sederhana.
.
Dukunganuntuk revisidan variasisees mendukungpembuatanvariasi yang beradadibawahnarnacabangdelta. Variasidibuat seearaotomatis apabilavariasiyangtelahmemilikisuatupenerusdiperiksauntukdiedit.
.
Kemampuanadministrasi.sees
memberikanfasilitas untuk merawat
penjelasantentang versi, mencetaksejarahversi item, membandingkanversi, menyisipkan informasi versi kedalam file secara otomatis, dsb.
. 202
Kemampuan kontrol program. Semua perubahan resmi terhadap file-file harns dibuat dengan memeriksa file yang terpengarnh untuk melakukan pengeditan
dan kemudian menyerahkanfIle yang telah dirubah kedalam sees sebagai versi barn. Apabila suatu file diperiksa untuk mengetahui perubahannya mungkin tidak ada seorangpunyang dapat memeriksafIle tersebut, sehingga daftar tidak mungkin teIjadi revisi yang tidak konsisten. sees menyimpan pemakai diperbolehkanuntuk membuka fIle dan hanya pemakai yang resmi yang berhak memeriksa dan mengedit fIle. sees juga memberikan bagian khusus untuk pertanyaan modifIkasi(MR),jumlah (kita akan membahasMR kemudian).
.
Kemampuan kontrol pembuatan. make memeilki kemampuan untuk menanyakansees tentang waktu pembuatan fIledalam ketergantunganfIle komputasi. makefile dapat berisikan perintah-perintah sees untuk memanggil versi bagi kompilasi.
Sistem sees tersusun dari tiga perintah utama dan beberapa perintah tambahan. Perintah utama ini adalah sbb :
.
admen diapakiuntukmenempatkanfIledibawahadministrasisees serta mengontrolpemakaiannya.
.
get dipakaiuntukmemeriksaversifIleuntukdieditdan dibaca.
.
delta dipakaiuntukmemeriksasatu fIleversibarn.
Diagram tentang aktivitas sees utama diberikat dalam gambar 9.1. Tiap versi sees memilikibilanganversi yang disebut sebagaiSID dari bentukberikut.
release.
level.
branch.
sequence
203
Gambar9.1 : Diagramaktifitassees. Tiap versi memilki tingkat dan release; nomor release dibedakan revisi utama dan nomor tingkat dipakai untuk membedakan revisi yang sedikit (minor). Cabang dan urutan bilangan ditambahkan kedalam variasi, bilangan cabang yang membedakan variasi tersebut, bilangan urutan membedakan revisi dan variasi. Sebagai gambaran, misalnya kita hendak menempatkan file myfile.c dibawah
sees. PeIintah admin-imyfile.c myfile.c menyebabkan sees menghasilkan file baseline yang disebut s.myfIle.cyang berisikan informasiadministrasisees dan isi yang asli dari myfile.c (prefix "s." merupakan konvensi sees yang diperlukan). Versi baseline dari myfile.c memilki SID.l.l perintah get dapat dipakai untuk mengakses myfile.c untuk diedit dengan mengetikkan get -e s.myfIle.c. apabila myfile telah diubah, maka dia akan diperiksa kembali dengan menggunakanperintah delta s.myfIle.c. SID untuk versi yang barn dari myfile.c adalah 1.2. Misalnya myfile.c telah diperiksa, diubah, dan diperiksa kembali beberapa kali yang menghasilkan string revisi dengan 1.1, 1.2, 1.3, dan 1.4 pada SID. Misalnya kita akan membuat variasi dari versi 1.3 maka perintah get -c -r 1.3 s.myfIle.c akan memanggil 1.3 untuk pengeditan.sees memahamibahwa versi yang barn ini merupakanvariasidari 1.3 (karena dia memilikipenerus, versi 1.4) dan memberinya nilai SID 1.3.1.1 bila perintah delta diapaki untuk memeriksa dalam variasitersebutbilanganini menunjukkanbah,waversiyang barn merupakan variasidari variasi 1.3.Revisi dari versi 1.3.1.1akan diberi nomor 1.3.1.2,1.3.1.3, dsb, sedangkan versi barn dari 1.3 akan diberi nomor 1.3.2.1, 1.3.3.1 dan sebagainya. Ringkasan dari penomoran ini dapat dilihat dalam gambar 9.2. 204
9.2.2 KONTROL PERUBAHAN Kontrol perubahan merupakan aktifitas mempertimbangkan, memutuskan, mendelegasikan tanggung jawab pada. dan memenatau perubahan item. Kontrol perubahan dibentuk sebagai satu kumpulan prosedur, biasanya ditekankan pada sistem data base untuk pendokumentasian dan pelacakan perubahan.
1.3.2.1
Variations
Gambar 9.2 : Pembuatan nomor sees. Perubahan dokumentasi dan pelacakan data base disebut sistem kontrol perubahan. Kontrol perubahan dapat bersifat informal pada proyek-proyekyang kecil, mungkin hanya dengan menggunakan logbook untuk melakukan dOkumentasidan pelacakan perubahan.Pada proyek-proyekyang besar prosedur kontrol perubahan yang ketat harus dibuat bersama dengan sistem yang menggunakan mesin untuk dokumentasidan pelacakan perubahan. Kegiatandan proses utama dari kontrol perubahan adalah sbb : 1.
Seseorang menyerahkan permintaan perubahan. Permintaan tersebut dinamakan MR dan pemberian permintaan tersebut dinamakan opening (pembukaan)MR. Biasanyaform,baik kertasmaupunelektronik,yang disebut modificationrequest form (MRF) diapaki untuk membuka MR. Contoh dari MRF adalah sbb : 205
Modification Request 110001 APPLICATION: ccount
TYPE:
sw
ORIG. NAME: Bill Frakes ROOM: 2J-502
PHONE: MACHINE:
SUN
7186
Date of
MR: 8/10/88
RELEASE
OCC:
DEPT: 3/50
DATE
1.0 45327
OCCURRED:
8/2/88
ATTACHMENTS: None. ABSTRACT
:
Incorrect
CSL output.
DESCRIPTION: The CSL count
produced
on correct C files is for all per-function an example and check the output
by ccount
one too small. The problem occurs counts; try by hand.
list.c
for
RELATED MRs: None.
EXPLANATION: Per-function CSL counting was turned off at the sight of a left curly bracket closing a function definition, not at end of the line with the closing curly bracket on it, thus failing to count comments on the last line of the function definition. STATUS:
Closed
TESTER:
Bill
DUE DATE: 08/08/88
PRIOR STATUS: Open
Frakes
CATGORYCHNG: Bug
fix.
RES. SUMMARY:Bug
was
RESOLUTION:
Changed counting
IMPACT:
Local
CHILDREN:
None
by programmer
fixed
C.
Fox.
where end-of-function flag routine.
change
to
counter.
was
set
in
c module.
MR dapat dibuka oleh pelanggan,pembuat, menejer,penguji, dokumen, atau beberapa dari kelompok tersebut. MR dapat menyebutkan kesalahan, kekeliruan, peningkatan dsb. Konsep yang perlu diperhatikan adalah MR child, yang terbaik dijelaskan dengan gambar. Apabila MR ditulis terhadap permintaan selama bagian tahap-tahap pengembangan lanjutan, maka perubahan juga cenderung 206
memerlukan perubahan lain dalam desain, kode, rencana test, dan produk dari tahap-tahap berikutnya. MR yang ditulis untuk mengubah produk tahap-tahap lanjutan ini dinamakan MR child dari MR asli. Contoh lain dari MR child adalah perubahan-perubahandari modul compile individual yang ditentukan oleh perubahan dalam header file yang umum. Disini MR yang mengubah modul compile adalah MR child pada MR untuk header. 2.
MR dikaji ulang dengan otoritas kontrol perubahan atau badan review MR yang menguji masing-masingMR serta memutuskannyapada kegiatan yang tepat. Badan review MR tersusun atas pembuat, menejer, penguji, dan sebagainya. Sering kali keputusan ini melibatkan pengelompokan MR berdasarkan kemampuan mereka. Sistem klasifIkasi seperti.berikut biasa digunakan : .
Tingkat kegunaan 1. Item tidak dapat dipakai, tidak dapat dipahami serta tidak dapat diproduksi karena masalah yang dilaporkan MR. Sebagai contoh MR melaporkan kerusakan software yang menyebabkan sistem rusak selama pemakaian khusus akan termasuk dalam tingkat kemampuan 1.
.
. .
Tingkatkemampuan2. Itemdapat dipakaitetapitidak dapatditerima karena maslahanyang dilaporkanMR. Sebagaicontoh,kasustest dengan kondisi input yang salah sebagian dapat masuk dalam klasifIkasi ini. Tingkat kemampuan 3. Item dapat dipakai tetapi MR melaporkan kegagalan untuk sesuai dengan standard dan petunjuk atau praktek. Sebagai contoh, MR melaporkan heading bagian terformat yang tidak benar dalam dokumen pemakai termasuk dalam katagori ini. Tingkat kemampuan 4. MR memerlukan peningkatan dan adaptasi. 4 Misalnya, permintaan port PC termasuk pada kategori ini.
Apabila MR telah dikelompokkan, maka badan review MR akan memutuskan cara untuk menyelesaikan masing-masing MR. Diantara kemungkinan ini adalah sebagai berikut:
. . .
.
Menginvestigasi MR dan membuat perubahan secepatnya. Menjadwalkan investigasi dan perubahan bila sumber-sumber telah tersedia.
MembedakankeputusantentangdisposisiMR sampaiyang akandatang. MenolakpermintaanyangdibuatMR.
207
3.
Apabila perubahan telah disetujui, otoritas pelacakan perubahan diberitahu dan meneruskan melacak perkembangan dari perubahan tersebut. Otoritas pelacakan perubahan dapat seorang manajer proyek, anggota staff yang bertanggung jawab atas pelacakkan perubahan, atau badab review MR.
4.
Perubahan harns direncanakan,dijadwalkan,dan diberikan kepada pembuat, diimplementasikan,dikajiulang, dan diverivikasi.Bila hal ini telah dilakukan, otoritas kontrol perubahan, diberitahu bahwa perubahan telah selesai. MR ditutup, dan perubahan menjadi bagian dari versi berikutnya pada item konfigurasi software.
Sistem kontrol perubahan biasanya dapat melaporkan status MR, membuat .statistik dan laporan ringkasan tentang aktifitas perubahan proyek, serta informasi dan pemberitahuan langsung tentang perubahan kepada masayarakat. Gambar 9.3 menjelaskan tentang proses kontrol perubahan. Sistem kontrol perubahan formal menggunakan .overhead manajemen yang penting dalam pengembangan dan perawatan. Konsekuensinya, item konfigurasi software biasanya ditempatkan dibawah kontrol perubahan pada saat mereka ditempatkan dibawah kontrol versi, biasanya, sebisa mungkin, diakhir tahap-tahap pengembangan.
9.2.3 Kontrol Pembuatan Konfigurasi software merupakan kumpulan dari versi-versi item. Konfigurasi awal dapat berisikan versi permulaan dari persyaratan dan dokumen desain, serta rencana imlementasi. Konfigurasi kedua dapat berisikan dokumentasi persyaratan awal serta rencana implementasi, dokumen desain yang direvisi, serta beberapa modul software serta kasus test unit. Konfigurasi yang kedua ini berisikan versi item tertentu. Kelompok yang penting dari item yang merupakan bagian konfigurasi software derived item, item-item yang dihasilkan dari item-item lain, biasanya dengan komputer. Misal dari item yang telah diubah ini mencakup modul obyek, file yang dapat dijalankan, data test, dan sebagainya. Item lain disebut nonderived item. Kontrol pembuatan adalah aktifitas dalam menentukan, melacak, dan membentuk konfigurasi software. Kontrol pembuatan terpusat pada sekitar kegiatan database untuk merawat spesifikasi lengkap dari konfigurasi software ketika item-tiem berubah dalam tahap-tahap pengembangan. Kontrol kendali item yang tidak diubah ini tidak sulit sampai terdapat lebih dari satu release dari suatu sistem; kemudian sampai munculnya masalah yang sulit. Kontrol pembuatan 208
Modifi~tion Raquest (MRI Originator
Test Organization
Software Build Group
Project Penlonnel
Responsible Person Bug-Fix Resolution
Project Management
Gambar 9.3
nonderived item biasanya dilakukan secara manuaL Kontrol pembuatan item derived yang efisien merupakan masalah yang sulit, tetapi dapat menghasilkan mekanisasi; banyak piranti yang dapat dipakai untuk kontrol pembuatan derived item. Piranti kontrol pembuatan yang utama dalam lingkungan UNIX adalah make yang mengotomatisasikan pembuatan derived item. make dibahas dalam Bab 7. sees memberikan dukungan terhadap kontrol pembuatan item nonderived dalam sistem penomoran versinya.
209
9.2.4 Pemantauan Proyek dan Manajemen Konfigurasi Disamping aktifitas utama manajemen konfigurasi, piranti manajemen.ini dapat membuat data untuk membantu pelacakan proyek. Sebagai contoh, sees dapat melaporkan barapa baris yang telah berubah dalam file proyek. Perubahan-perubahan ini, atau delta sering disamakan dengan kesalahan yang dibetulkandan digunakandalammetrikuntukmemperkirakankerapatankesalahan. Sistem pelacakan menejemen perubahan yang telah diotomatisasikan dapat membuatdata proyek lebihrind, sepertijumlah MR yang dibagi lagi oleh katagori kemampuan. Mereka juga dapat membuat panjang waktu yang diperlukan untuk menutup MR baik jumlah MR maupun waktu menutupinya nampak secara luas dalam laporanproyek yang digunakan oleh menejemenproyek untuk pembuatan keputusan.make dapat dipakaiuntuk memanggilprogram untuk merekamjumlah item, nomor item dari nom~r item yang telah dicompile. Data ini dapat dimanfaatkan dalam memperkirakan kesalahan modul sumber dan efisiensi pembetulan kesalahan.atau usaha peningkatan program.
9.2.5 Ringkasan. Menejemen konfigurasi mencakup tiga aktifitas yang saling berhubungan : control veresi, kontrol perubahan dan kontrol pembuatan. Sistem UNIX memberikanpirantiuntukmendukungkegiatanini secaraterpisah,denganbeberapa kemampuaRuntuk mem~ukan mereka. Ini merupakansalah satu bidang dimana diperlukan dukungan piranti yang lebih canggih.
210
