1. PENDAHULUAN

2. 1.1 REKAYASAERANGKAT
P 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.
C
1.2. SISTEMUNIXDANBAHASA
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

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

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

5. 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 soft-
ware.
. 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 SOFT-
WARE
Software adalah obyek tertentu yang dapat dijalankan seperti kode sumber,
kode obyek, atau sebuah program yang lengkap. Produk software adalah soft-
ware 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

6. khusus ; dan (3) Data yang digunakan untuk testing, rnelacak proyek dan
sebagainya.Para insinyursoftwarernernbantumenghasilkansebagianOOsar roduk
p
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
KATEGORI UKURAN PROYEK
lI
.
. u un---nn
!~~tlll~liil!liii!I~~II:i:ili::!i!ii!~~:lii:i
n
~Ili:iilillillilll.!'
_. _0000
Tidak penting 0-4 Minggu Utilitas pendek
Keeil 1-6 Bulan Pustaka fungsi
Sedang 0.5-2 Thn Produksi Compiler C
Besar 2-3 Tahun Sistem Operasi keeil
Sangat besar 4-5 Tahun Sistem Operasi besar
Besar sekali 5-10 Tahun 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

7. 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 soft-
ware dalam proyek software disebut metodologi proyek. Memilih metodologi
7

8. 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
PEMBUATANOFTWARE
S SERTA
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 temporal-
yang 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

9. 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 soft-
ware 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 ATRIBUT
KUALITASOFTWARE
S
Kualitas dihubungkan dengan pemenuhan tuntutan pemakai. Salah satu eara
menghubungkan kualitas dengan pemakai adalah dengan mengikuti Juran dalam
9

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

11. 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 menunjukkanentangearapemakaian
t sumberkomputasi
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

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