PENDAHULUAN
1.1 REKAYASA PERANGKAT LUNAK Pada tanggal 15 Januari 1990 jaringan jarak jauh manual AT&T mengalami gangguan selama sembilan jam karena adanya kerusakan software. Jutaan hubungan telepon terputus. Dengan sendirinya bisnis seperti biro-biro travel yang menggantungkan pada jaringan tersebut juga mengalami gangguan. Peristiwa ini merupakan salah satu petunjuk akan pentingnya perangkat lunak serta dampaknya yang berpengaruh pada masyarakat bila terjadi kerusakan padanya. Ilmu yang membicarakan masalah seperti diatas adalah Rekayasa Perangkat Lunak. Rekayasa Perangkat Lunak telah dikenal sebagai bidang ilmu sejak tahun 1960-an. Ole~ karena itu ini masih relatif baru, maka Rekayasa Perangkat Lunak ini belum memiliki banyak dasar-dasar ilmiah ( scientific basis ). Sebenarnya para pakar perangkat lunak ini tidak setuju dengan definisi Rekayasa Perangkat Lunak itu sendiri. Rekayasa Perangkat Lunak kita definisikan sebagai disiplin managerial dan teknis yang berhubungan dengan penemuan sistematik, produksi dan maintenance sistem software yang berkualitas tinggi, disampaikan pada waktu yang tepat serta memiliki harga yang mahal. Rekayasa Perangkat Lunak meninjau teori dari berbagai bidang seperti manajemen, ekonomi, matematik dan komputer science. Kita memfokuskan pada salah satu dari bidang yang luas ini - cara menggunakan lingkungan pemrograman untuk menghasilkan .>isteinperangkat lunak yang berkualitas tinggi. Khususnya kita akan membicarakan cara menulis, sistem seperti ini dalam lingkungan bahasa C sistem UNIX. Dengan sendirinya penekanan kita adalah pada sisi teknis Rekayasa Perangkat Lunak, bukan sisi managerial.
1.2. SISTEMUNIXDANBAHASAC UNIX adalah sistem operasi time-shared (dapat dipakai bersama-sama) yang pertama kali ditulis oleh Ken Thompson dari Bell Laboratories pada tahun 1969. UNIX memiliki dua bagian utama. Kernel UNIX merupakan satu set fungsi yang sering dipakai yang tersimpan dalam main memori. Kernel ini menjadualkan pekerjaan, kontrol, perangkat keras, serta mengatur input dan output. UNIX akan menginterpretasikan perintah yang dikirim kedalam sistem. UNIX juga sering dipakai untuk menunjukkan set perangkat dan utilitas - editor , compiler, 2
Software Engineering Tool, dan sebagainya - yang khusus ada pada sistem tersebut. Terdapat versi UNIX sistem yang dikenal adalah AT & T UNIX sistem V, dan Berkeley UNIX yang secara resmi dikenal sebagai UCB 4XBSD. Versi-versi UNIX semuanya mirip, namun mereka berbeda dalam implementasi dan piranti-piranti serta utilitas-utilitas yang mereka sediakan.Sebagai contoh, terdapat shell UNIX : Bourne Shell, C Shell, dan Korn Shell. Semua shell ini dapat dipakai dengan kernel yang berbeda. Bahasa C ditulispada tahun 1970oleh DennisRitchieThompson,dan Ritchie menulis kembali kernel UNIX dalam C pada awal tahun 1970, dan sejak itu, UNIX dan C telah digabungkau.Bahasa C pada awalnya ditulis sebagai alternatif bagi bahasa rakitan pemrograman sistem. Hal ini karena C memberikan banyak kebebasan bagi pemrograman. Bahasa ini memungkinkan kita untuk mengakses tingkat rendah kedalam mesin. C dikenal sebagai bahasa yang dapat dipakai untuk menghasilkan kode yang cepat dan efisien.Bahasa C telah menjadi begitu terkenal, disamping pemrogramansistem,C dipakaijuga untukmembuatsistemsoftwareuntuk aplikasi yang besar. Generasi terakhir dari sistem switeling pada B~ll Laboratories yang berisikan jutaan baris kode, ditulis dalam C. Pendapat bahwa C merupakanbahasa yang baik untuk engineering sistem berskala besar, masih diperdebatkan. Dengan adanya data empiris yang cukup terkumpul, maka kita dapat mengetahui bahwa bahasa ini telah dapat dipakai dengan baik untuk membuat sistem yang besar. Bukti bahwa UNIX I C telah begitu terkenal adalah adanya banyak buku yang membahas UNIXIC tersebut. Buku ini menjelaskan tentang bahasa C dan sistem UNIX serta memberikan bimbingan yang rinei tentang pemakaiannya. Namun dalam buku ini tidak terdapat bimbingan rinei tentang .penggunaan perangkatdan teknik yang kita bicarakan.Tujuan kita adalah untuk menempatkan UNIXIC dalam konteks sistem engineering software yang besar - untuk menunjukkancara penggunaanUNIXICmelalui seluruh tahap untuk mendukung proyek engineering perangkat lunak.
1.3. BENI DALAMREKAYASA PERANGKAT LUNAK Meskipun telah banyak sumbangan teknis yang dibuat bagi Rekayasa Perangkat Lunak (misalnya,pengembanganbahasa pemrograman tingkat tinggi) seni dalam bidang ini masih jauh dari yang diinginkan para Rekayasa Perangkat 3
Lunak. Praktek yang sering dipakai biasanya lebih buruk. Proyek pengembangan software sering menghasilkan produktifitas yang rendah, dan produk software biasanya penuh kesalahan dan tidak memenuhi kehendak pemakai. Untuk menggambarkan masalah ini, mari kita pelajari tentang penemuan studi dari sembilan kontrak pengembangan Software Departemen Pertahanan USA, yang bertotaI $ 6,8 juta. . Untuk softwareyang telah di kirim namun tidakpemah dapat dipakai dengan baik diperlukan $ 3,2 juta. . Untuk Software yang telah dibayar tetapi tidak terkirim, diperlukan $ 1,95 juta. . Untuk software yang telah dikirim dan dipakai namun harns diperbaiki sebanyak $ 1,3 juta. Dari $ 6,8 juta, $ 119.000dipakaiuntuk softwareyang dipakaitanpa diadakan perubahan lagi. Namun sayangnya, pemborosan seperti ini merupakan hal yang umum. Sebagian besar organisasi teknis yang besar sering terjadi kerusakan software. Meskipun kegagalan proyek software sering disebabkan terutama oleh masalah managerial, pemborosan sumber teknis, sebab-sebab inilah yang menyebabkan biaya menjadi tinggi. Misalnya, salah satu sumber pemborosan yang terkenal dalam masalah teknis adalah kegagalan untuk menggunakan software kembali.
.
~mareo memperkirakanbahwarata-rataproyekhanyamelakukanpemakaian ulang sebanyak 5 % kode, meskipun sebenarnya bahwa kode .yang jumlahnya lebih banyak dapat digunakan. Masalah teknis ientang eara melakukan desain, katalog, penyimpanan dan pemanggilan kembali perangkat lunak yang dapat dipakai ulang masih belum terpecahkan. Salah satu aIasan dikembangkannya perangkat lunak UNIX karena UNIX berisikan banyak piranti keeil yang dapat dipakai kembali.HaIini sangat penting dalam Rekayasa Perangkat Lunak. Kepustakaan fungsi yang dapat digunakan kembali merupakan kelebihan yang terdapat pada bahasa C. Kita membahas masalah ini lebih secara rinei pada bab 6. Apa yang dapat dilakukan terhadap keadaan Rekayasa Perangkat Lunak yang belum lengkap tersebut ? Salah satu metodenya adalah dengan mempelajari secara lebih baik lagi mengenai masalah RekayasaPerangkat Lunak serta tentang teknik dan piranti terbaik yang ada untuk memecahkannya. Tugas ini tidaklah cukup bila hanya dibebankan dalam pelajaran akademik dan industri' tentang pemrograman dan Rekayasa Perangkat Lunak. Dalam pengalaman kita bahwa membuat serta mengajarkanRekayasa Perangkat Lunak. 4
memperkerjakan dan mengarahkan para insinyur software serta berkomunikasi dengan para pembuat software dalam berbagai proyek dapat diketahui bahwa terdapat banyak kekurangan pengetahuan tentang masalah Rekayasa Perangkat Lunak, serta terdapat praktek yang tidak benar. Beberapa observasi yang tidak benar mengikuti:
.
.
Manajer yang tidak mempunyai latar belakang Rekayasa Perangkat Lunak yang bertanggungjawab pada pekerjaan teknis sebagian besar proyek software. Para pekerja yang hanya memiliki pengalaman sedikit dibidang Rekayasa PerangkatLunak yang bertanggung jawab pada tugas teknis yang sulit, seperti merancang dan mengimplementasikan sebagian besar sistem software, dengan tidak memiliki petunjuk dan latihan teknis yang cukup.
.
Para lulusan program komputer science pada sebagian besar universitas yang belum pemah mengenal Rekayasa Perangkat Lunak, yang tidak menggunakan teknik dan piranti dalam membuat produk software yang berkualitas tinggi.
Banyak program komputer science yang tidak memberikan pelajaran Rekayasa Perangkat Lunak, bila mereka memberikannya pelajaran tersebut bersifat pilihan dan titik utamanya pada pemrograman.
1.4. PROYEK, METODOLOGI DAN PROD UK SOFTWARE Software adalah obyek tertentu yang dapat dijalankan seperti kode sumber, kode obyek, atau sebuah program yang lengkap. Produk software adalah software ditambah dengan semua item dan pelayanan pendukung yang secara keseluruhan dapat memenuhi kebutuhan pemakai. Produk software memiliki banyak bagian yang meliputi manual, referensi, tutorial, instruksi instalasi, data sampel, pelayanan pendidikan, pelayanan pendukung teknis dan sebagainya. Para insinyur software menghasilkan produk software, bukan hanya software. Semua yang dihasilkan oleh proyek software adalah produk kerja (work product). Produk kerja meliputi (1) Dokumen engineering yang dipakai untuk menentukan, mengontrol, dan memantau usaha kerja ; (2) Obyek yang dijalankan seperti prototipe, kendali test (test harness), dan piranti pengembangan tujuan
5
khusus ; dan (3) Data yang digunakan untuk testing, rnelacak proyek dan sebagainya.Para insinyursoftwarernernbantumenghasilkansebagianOOsarproduk kerja karena rnereka rnernilikikemarnpuan teknis. Kenyataannya para insinyur software sering rnenggunakan waktu yang lama untuk pekerjaan produk kerja non-software, khususnya dokurnen, daripada rnengerjakan pekerjaan software.
1.5. TIPEDANUKURANPROYEKSOFTWARE
.
Proyek software rnerniliki berbagai ukuran. Salah satu cara untuk rnenggolongkan ukuran tersebut adalah dengan baris kode seperti dalam taOOI 1.1.
u ...............__. .................... uuu.u
lI .
KATEGORI UKURAN PROYEK
.
u
un---nn
n
_.
_0000
!~~tlll~liil!liii!I~~II:i:ili::!i!ii!~~:lii:i ~Ili:iilillillilll.!'
Sangat besar
0-4 Minggu 1-6 Bulan 0.5-2 Thn 2-3 Tahun 4-5 Tahun
Besar sekali
5-10 Tahun
Tidak penting Keeil Sedang Besar
Utilitas pendek Pustaka fungsi Produksi Compiler C Sistem Operasi keeil Sistem Operasi besar Sistem switching
Proyek software yang paling besar ini memerlukan ribuan programer, manajer dan personal pendukung. Fungsi dan me sistern jumlahnya .puluhan dari ribuan dan dapat didistribusikan. ke banyak rnesin. Perubahan yang dilakukan terhadap sebuah file dapat rnengakibatkan ratusan file lainnya - dan sernua orang yang OOkerjadengan file-file tersebut. Inilah kerumitan pada hubungan intern diantara sernua elernen sistern ini yang rnernbedakan Rekayasa Perangkat Lunak. Kasus ini akan sulit bagi rnereka yang OOlurnpernah OOkerjadilingkungan proyek besar, untuk rnenerirna kerumitan tersebut. Ini adalah salah satu penghalang dalam pengajaran Rekayasa Perangkat Lunak. 6
Mereka yang telah faham dengan teknik Rekayasa Perangkat Lunak untuk proyek keeil mungkin mengira bahwa teknik tersebut akan cukup bila dipakai untuk proyek besar. Pendapat ini biasanya tidaklah benar misalnya piranti Rekayasa Perangkat Lunak kadang-kadang tidak dapat dipakai untuk sistem terdistribusi. Teknik manajemen perubahan informal untuk kelompok yang terdiri dari lima pembuat program tidak dapat dipakai untuk kelompok yang berjumlah 50 orang. Praktek Rekayasa Perangkat Lunak merupakan hal yang penting untuk proyek pada semua ukuran. Untuk proyek yang sangat besar dan besar sekali praktek tersebut sangat diperlukan karena sistem yang berukuran besar seperti ini tidak akan dapat dibuat tanpa diadakannya praktek diatas. Terdapat bukti empiris bahwa ukuran proyek memiliki pengaruh yang besar pada atribut proyek penting seperti produktifitas programer individual, yang menurun drastis pada saat ukuran tim pengembangan dan sistem meningkat. Akibat ini disebabkan karena kurangnya koordinasi dan komunikasi pada proyek besar. Conte dan kawan-kawan memberikan pembahasan yang menarik tentang studi empiris dari faktor yang mempengaruhi proyek software. Faktor lain yang disebabkan oleh ukuran proyek adalah jumlah dokumentasi yang diperlukan. Sebagai contoh proyek yang tidak penting misalnya program metrik kode sumber yang sederhana seperti account, mungkin tidak memerlukan dokumen engineering apapun, dan tidak memerlukan dokumentasi pemakai yang lebih banyak selain halaman manual. Namun sebaliknya, proyek berukuran sedang, seperti compiler C, hendaknya memiliki satu set dOkumen engineering yang paling tidak meliputi eksplorasi konsep dan dokumen kelayakan, dokumen persyaratan, rencana proyek, dokumen disain, test plan, dan ringkasan proyek. Paling tidak pemakai memerlukan manual, tutorial, kartu referensi cepat, instruksi instalasi dsb. Merupakan hal yang tidak berguna bila kita menuntut dokumentasi utilitas metrik sebanyak compiler C tersebut. Namun demikian tuntutan semacam ini kadang-kadang dapat terpenuhi. Hal ini merupakan contoh yang umum tentang praktek Rekayasa Perangkat Lunak yang tidak tepat pemakaiannya. Proyek-proyek juga berbeda dalam hal tipenya. Tuntutan unjuk kerja, disain, strategi implementasi, metode pengujian dan maslah yang timbul secara substansial berbeda untuk program sistem operasi, program aplikasi keilmuan, program aplikasi. bisnis serta sistem real-time. Perbedaan produktifitas diantara proyek software yang berbeda telah di obsevasi. Praktek-praktek Rekayasa Perangkat Lunak harus disesuaikan dengan proyek-proyek yang memiliki ruang lingkup yang berbeda. Set dari piranti teknik serta metode yang digunakan oleh para insinyur software dalam proyek software disebut metodologi proyek. Memilih metodologi
7
yang tepat untuk sebuah proyek bukanlah hal yang mudah. Pimpinan insinyur software hams membentukmetodologiproyek dengan memilih dari berbagai alat teknik dan metode yang ada yang sesuai untuk proyek mereka.
1.6.
TAHAP-TAHAP PEMBUATAN SOFTWARESERTA MODELNYA Metodologi proyek diterapkan dalam konteks tahap-tahap pengembangan software (software ~ive cycle) - urut-urutan tahap pengembangan, yang disebut fase, yang merupakan tahapan yang hams dilalui oleh produk software dari konsep awal sampai tahap terakhir. Model tahap-tahap tersebut merupakan penyajian dari tahap-tahap pengembangan software yang juga dapat berisikan alur informasi, saat penentuan keputusan dsb. Kita menekankan bahwa model tahap-tahap tersebut hanyalah merupakan model. Tidak ada proyek sesungguhnya yang berlaku secara tepat sebagaimana yang ditunjukkan oleh suatu model dan penyimpangan ini akan banyak. Fase-fase dari model tahapan penyusunan dapat merupakan fase temporalyang membentuk urutan dalam waktu - atau fase logis - yang menunjukkan tahap-tahap bukan rriembentuk urutan temporal. Sebagai contoh impleroentasi secara logis akan mendahului pepguj,ian namun bagian fase implementasi dan pengujian dapat terjadi secara serempak. Jadi model tahapan yang menggunakan fase logis dapat memiliki fase implementasi sebelum fase pengujian, sedangkan model yang menggunakan fase temporal mungkin fase-fase ini akan bertumpang tindih. Model tahapan ini dapat digunakan secara tertulis untuk memberikan tugas pada kejadian tahapan pengembangan atau secara deskriptif untuk merecord peristiwa-peristiwa pada tahapan tersebut. Banyak model tahap pengembangan sistem yang telah diajukan. Sebagian besar model-model tersebut memiliki kesamaan pada tahap-tahap fundamental, tetapi berbeda dalam hal terminologi, penekanan, keluwesan dan cakupannya. Model temporal prekriptif yang rinci bermanfaat dalam suatu rencana proyek karena model ini memetakan jalannya proyek yang dikehendaki. Model temporal deskriptifbermanfaat dalam pelaksanaan dokumentasi tahap-tahap pengembangan serta dalam menganalisa proyek bila telah selesai. Model tahapan pengembangan yang kita pakai dalam buku ini adalah model logis preskriptif umum. Model ini bersifat umum karena hanya memberikan
8
urutan Jogis tentang fase-fase pengembangan. Meskipun model ini akan lebih baik untuk menyajikantemporal khusus namun tidak ada model seperti ini yang dapat untuk semua proyek software. Seperti bagian-bagian lain dari metodologi software, model tahap pengembangankhusus harus dibentuk untuk proyek software khusus. Model kita adalah model air terjun ( waterfall ) standard yang berisikan fase-fase logis berikut : Fase analisis kelayakan dan eksplorasi konsep. MengidentifIkasikebutuhan untuk melakukan otomatisasi proses dan menganalisa kelayakan proyek.
. .
. . .
.
Fase spesifIkasipersyaratan.Menganalisadan mendokumentasikan persyaratansistem.Dokumentasipersyaratansecarajelas harus menyebutkan apa yang akan dilakukan oleh sistem yang diproyeksikan, unsur apa yang akan diperlukan oleh produk software serta karakteristik apa yang harus dimiliki oleh unsur produk. Fase disain. Mendisain sistem dan mendokumentasikan sistem. Dokumen disain menentukan eara pembuatan sistem software untuk memenuhi persyariltantersebut. Fase implementasi. Menulis software. Fase pengujian.Meneoba softwareuntuk mengetahuiapakahtelah memenuhi persyaratannya.
Fase perawatan.Mengikutipenempatanproduk software.membetulkan
kesalahan; mengubah dan memperluas sistem. Model ini seperti model lainnya hanya memberikan cara yang sebenarnya dikerjakan oleh suatu proyek ( gambar 1.1 ).. Sangat banyak hal yang tidak dlramalkan terjadi pada proyek software untuk semua model yang lebih banyak daripada petunjuk umum. Model waterfall sering dikritik karena hanya sedikit yang sama dengan kenyataan proyek. Namun model ini merupakan model yang banyak dipakai dalam proyek besar. Lebih lanjut model ini bermanfaat bagi segi pedagogis, itulah sebabnya kita menggunakan model tersebut.
1.7 ATRIBUTKUALITAS SOFTWARE Kualitas dihubungkan dengan pemenuhan tuntutan pemakai. Salah satu eara menghubungkan kualitas dengan pemakai adalah dengan mengikuti Juran dalam
9
mendefinisikan kuaIitas sebagai (kecocokan penggunaan). Juran membedakan dua aspek keeocokan penggunaan: Koleksi kemampuan produk yang memenuhi tuntutan pemakai dan bebas dari kekurangan. Sebuah produk dengan koleksi kemampuan yang dapat memenuhi tuntutan pemakai maka dapat memberikan kepuasan pembeli. Terbebas dari kekurangan dapat menghindari ketidakpuasan pembeli. Kedua aspek ini dapat memenuhi tuntutan pemakai ( kualitas tinggi ).
Concept exploretlon and feasibility ene'ysls
Gambar
1.1
Model pengembangan software waterfall. KuaIitas produk software yang telah selesai terutama tergantung pada kuaIitas produk kerja yang dihasilkan selama pengembangan dan perawatan. Pengertian kuaIitas sebagai fitness for use menghasilkan atribut untuk mengevaIuasi kuaIitas produk kerja yang berdasarkan pada tuntutan pemakai dari produk tersebut. Misalnya, dokumen spesifikasi tuntutan dipakai oleh pembeli dan pembuat untuk merecord keputusan dan persertujuan tentang .produk .yang akan dibuat, oleh disainer sebagai sumber definitif tenteng informasi produk yang. akan didisain, bagi dokumenter merupakan sumber informasi tentang eara kerja produk tersebut serta earn pemakaiannya, bagi penguji merupakan sumber informasi tentang earn sistem tersebut berlaku hubungannya untuk meneoba data, dan tentang parameter unjuk kerja. Tuntutan ini memberikan motifasi pada atribut kuaIitas khusus untuk
10
dokumen spesiftkasituntutan - misalnyasemua persyaratandapat di test, tepat, dan jelas; bahwa keterbatasan unjuk ketja harus secara jelas ditunjukkan; dsb. Atribut kualitas yang hampir sarna dapat dihasilkan untuk semua produk kerja; temyata sebagian produk ketja memiliki atribut kualitas yang meneakup : Betul. Deftnisi betul beragarn.Misalnya dokumen tuntutan betul bila seeara tepat dapat menjelaskan fungsi dan kekayaan yang diperlukan oleh suatu produk; Softwaredikatakanbenarjika telah memenuhipersyarataninput dan outputnya; dokumentasi program dikatakan betul bila secara akurat dapat menjelaskan program.
. .
Eftsien.Atributini menunjukkantentangearapemakaiansumberkomputasi secara baik. Sebagai eontoh, Quietsort lebih eftsien daripada Bubblesort sebab didapat melakukan sort daftar dengan instruksi mesin yang lebih sedikit.
.
Perawatan. Atribut ini dapat diterapkan untuk semua produk keIja tapi sebagian besar sering diaplikasikan untuk software. Perawatan ini menunjukkan betapa mudahnya eara melakukan perbaikan, perubahan atau perluasan.
.
Mudah dipindahkan (Portable). Atribut ini menunjukkan betapa mudahnya software dapat dipindah tergantung dari jenis lingkungan.
.
Mudah dibaea (Readable). Atribut ini berlaku untuk semua produk kerja tekstual atribut ini menunjukkan betapa mudahnya kita memahami produk kerja.
. .
.
Dapat dipereaya (Reliable).Atribut ini biasanya berlakuunlJk software serta 'mengaeu pada kemampuan software untuk dijalankan sesuai dengan permintaan untuk periode pemakaian tambahan. Dapatdipakailagi (Reuseable).Atributini biasanyaditerapkanpada perangkat lunak dan berkaitan dengan seberapa baik program dapat melanjutkan operasinya seeara betul dalam mengatasi masukkan yang salah. Kuat (Rebost). Atribut ini untuk software serta mengaeueara suatu program meneruskan operasinya dengan benar.
.
Dapat di uji (Testable).Atribut ini menunjukbetapa mudahnya produk kerja dieoba seeara penuh, akurat, efisien dan sistimatisuntuk mengetahuiapakah dia memenuhi persyaratan.
.
Memilikidokumentasiyang baik (Welldokumented).Atributini menunjukkan betapa baiknya produk softwaredidukung oleh materialyang seeara lengkap menjelaskan instalasinya, operasi, perawatan, perbaikan, pengembangan, konstruksi dan evolusi.
11
Atribut kualitas memiliki hubungan yang kompleks. Misalnya kode yang sangat dioptimalkan sering padat tapi sukar dibaca. Kode yang sukar dibaca biasanya perawatannya kurang. Sebaliknya kode yang dioptimalkan biasanya lebih efisien. Progamer dapat meningkatkan atribut kualitas tertentu pada programnya, meskipun biasanya mengorbankanbagian yang lain. Para insinyur software hams memutuskan atribut kualitas mana yang paling penting untuk proyek mereka. Misalnya, bila sebuah sistem diharapkan dapat tahan lama maka kemampuan perawatandapat merupakanhal yang terpenting,sedangkanefisiensidapat bersifat kurang penting. Teknik standard dan praktek Rekayasa Perangkat Lunak dapat dipakai untuk mempromosikan perawatan dan portabilitas, meskipun mungkin mengorbankan efisiensi. Pembahasan ini sekali lagi menunjukkan arti penting dan kesulitan dalam menentukan metodologi proyek yang tepat.
12
