bab1

12
PENDAHULUAN

Upload: ratzman-iii

Post on 24-May-2015

137 views

Category:

Documents


5 download

TRANSCRIPT

Page 1: Bab1

PENDAHULUAN

Page 2: Bab1

1.1 REKAYASAPERANGKATLUNAK

Pada tanggal 15 Januari 1990 jaringan jarak jauh manual AT&T mengalamigangguan selama sembilan jam karena adanya kerusakan software. Jutaanhubungan telepon terputus. Dengan sendirinya bisnis seperti biro-biro travel yangmenggantungkan pada jaringan tersebut juga mengalami gangguan. Peristiwa inimerupakan salah satu petunjuk akan pentingnya perangkat lunak serta dampaknyayang berpengaruh pada masyarakat bila terjadi kerusakan padanya.

Ilmu yang membicarakan masalah seperti diatas adalah Rekayasa PerangkatLunak. Rekayasa Perangkat Lunak telah dikenal sebagai bidang ilmu sejak tahun1960-an. Ole~ karena itu ini masih relatif baru, maka Rekayasa Perangkat Lunakini belum memiliki banyak dasar-dasar ilmiah ( scientific basis ). Sebenarnyapara pakar perangkat lunak ini tidak setuju dengan definisi Rekayasa PerangkatLunak itu sendiri. Rekayasa Perangkat Lunak kita definisikan sebagai disiplinmanagerial dan teknis yang berhubungan dengan penemuan sistematik, produksidan maintenance sistem software yang berkualitas tinggi, disampaikan pada waktuyang tepat serta memiliki harga yang mahal.

Rekayasa Perangkat Lunak meninjau teori dari berbagai bidang sepertimanajemen, ekonomi, matematik dan komputer science. Kita memfokuskan padasalah satu dari bidang yang luas ini - cara menggunakan lingkungan pemrogramanuntuk menghasilkan .>isteinperangkat lunak yang berkualitas tinggi. Khususnyakita akan membicarakan cara menulis, sistem seperti ini dalam lingkungan bahasaC sistem UNIX. Dengan sendirinya penekanan kita adalah pada sisi teknisRekayasa Perangkat Lunak, bukan sisi managerial.

1.2. SISTEMUNIXDANBAHASAC

UNIX adalah sistem operasi time-shared (dapat dipakai bersama-sama) yangpertama kali ditulis oleh Ken Thompson dari Bell Laboratories pada tahun 1969.UNIX memiliki dua bagian utama. Kernel UNIX merupakan satu set fungsi yangsering dipakai yang tersimpan dalam main memori. Kernel ini menjadualkanpekerjaan, kontrol, perangkat keras, serta mengatur input dan output. UNIX akanmenginterpretasikan perintah yang dikirim kedalam sistem. UNIX juga seringdipakai untuk menunjukkan set perangkat dan utilitas - editor , compiler,

2

Page 3: Bab1

Software Engineering Tool, dan sebagainya - yang khusus ada pada sistemtersebut. Terdapat versi UNIX sistem yang dikenal adalah AT & T UNIX sistemV, dan Berkeley UNIX yang secara resmi dikenal sebagai UCB 4XBSD.Versi-versi UNIX semuanya mirip, namun mereka berbeda dalam implementasidan piranti-piranti serta utilitas-utilitas yang mereka sediakan.Sebagai contoh,terdapat shell UNIX : Bourne Shell, C Shell, dan Korn Shell. Semua shell inidapat dipakai dengan kernel yang berbeda.

BahasaC ditulispada tahun 1970olehDennisRitchieThompson,dan Ritchiemenulis kembali kernel UNIX dalam C pada awal tahun 1970, dan sejak itu,UNIX dan C telah digabungkau.BahasaC pada awalnyaditulis sebagai alternatifbagi bahasa rakitan pemrograman sistem. Hal ini karena C memberikan banyakkebebasan bagi pemrograman.

Bahasa ini memungkinkan kita untuk mengakses tingkat rendah kedalammesin. C dikenal sebagai bahasa yang dapat dipakai untuk menghasilkan kodeyang cepat dan efisien.Bahasa C telah menjadi begitu terkenal, disampingpemrogramansistem,C dipakaijuga untukmembuatsistemsoftwareuntukaplikasiyang besar. Generasi terakhir dari sistem switeling pada B~ll Laboratories yangberisikan jutaan baris kode, ditulis dalam C.

Pendapat bahwa C merupakanbahasa yang baik untuk engineering sistemberskala besar, masih diperdebatkan. Dengan adanya data empiris yang cukupterkumpul, maka kita dapat mengetahui bahwa bahasa ini telah dapat dipakaidengan baik untuk membuat sistem yang besar.

Bukti bahwa UNIX I C telah begitu terkenal adalah adanya banyak bukuyang membahas UNIXIC tersebut. Buku ini menjelaskantentang bahasa C dansistem UNIX serta memberikan bimbingan yang rinei tentang pemakaiannya.Namun dalam buku ini tidak terdapat bimbingan rinei tentang .penggunaanperangkatdan teknikyang kita bicarakan.Tujuan kita adalah untuk menempatkanUNIXIC dalam konteks sistem engineering software yang besar - untukmenunjukkancara penggunaanUNIXICmelalui seluruhtahap untuk mendukungproyek engineering perangkat lunak.

1.3. BENI DALAMREKAYASA PERANGKAT LUNAK

Meskipun telah banyak sumbangan teknis yang dibuat bagi RekayasaPerangkat Lunak (misalnya,pengembanganbahasa pemrograman tingkat tinggi)seni dalam bidang ini masih jauh dari yang diinginkan para Rekayasa Perangkat

3

Page 4: Bab1

Lunak. Praktek yang sering dipakai biasanya lebih buruk. Proyek pengembangansoftware sering menghasilkan produktifitas yang rendah, dan produk softwarebiasanya penuh kesalahan dan tidak memenuhi kehendak pemakai. Untukmenggambarkan masalah ini, mari kita pelajari tentang penemuan studi darisembilan kontrak pengembangan Software Departemen Pertahanan USA, yangbertotaI $ 6,8 juta.

. Untuk softwareyang telah di kirim namun tidakpemah dapat dipakaidenganbaik diperlukan $ 3,2 juta.

. Untuk Software yang telah dibayar tetapi tidak terkirim, diperlukan $ 1,95juta.

. Untuk software yang telah dikirim dan dipakai namun harns diperbaikisebanyak $ 1,3juta.

. Dari $ 6,8juta, $ 119.000dipakaiuntuk softwareyang dipakaitanpa diadakanperubahan 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 masalahmanagerial, pemborosan sumber teknis, sebab-sebab inilah yang menyebabkanbiaya menjadi tinggi. Misalnya, salah satu sumber pemborosan yang terkenaldalam masalah teknis adalah kegagalan untuk menggunakan software kembali.

~mareo memperkirakanbahwarata-rataproyekhanyamelakukanpemakaianulang sebanyak 5 % kode, meskipun sebenarnya bahwa kode .yang jumlahnyalebih banyak dapat digunakan. Masalah teknis ientang eara melakukan desain,katalog, penyimpanan dan pemanggilan kembali perangkat lunak yang dapatdipakai ulang masih belum terpecahkan.

Salah satu aIasan dikembangkannya perangkat lunak UNIX karena UNIXberisikan banyak piranti keeil yang dapat dipakai kembali.HaIini sangat pentingdalam Rekayasa Perangkat Lunak. Kepustakaan fungsi yang dapat digunakankembali merupakan kelebihan yang terdapat pada bahasa C. Kita membahasmasalah ini lebih secara rinei pada bab 6.

Apa yang dapat dilakukan terhadap keadaan Rekayasa Perangkat Lunakyang belum lengkaptersebut ? Salah satu metodenyaadalah dengan mempelajarisecara lebih baik lagi mengenai masalah RekayasaPerangkatLunak serta tentangteknik dan piranti terbaik yang ada untuk memecahkannya.

Tugas ini tidaklah cukup bila hanya dibebankan dalam pelajaran akademikdan industri' tentang pemrograman dan Rekayasa Perangkat Lunak. Dalampengalaman kita bahwa membuat serta mengajarkanRekayasa PerangkatLunak.

4

Page 5: Bab1

memperkerjakan dan mengarahkan para insinyur software serta berkomunikasidengan para pembuat software dalam berbagai proyek dapat diketahui bahwaterdapat banyak kekurangan pengetahuan tentang masalah Rekayasa PerangkatLunak, serta terdapat praktek yang tidak benar. Beberapa observasi yang tidakbenar mengikuti:

. Manajer yang tidak mempunyai latar belakang Rekayasa Perangkat Lunakyang bertanggungjawab pada pekerjaan teknis sebagian besar proyek soft-ware.

. Para pekerja yang hanya memiliki pengalaman sedikit dibidang RekayasaPerangkatLunak yang bertanggung jawab pada tugas teknis yang sulit, sepertimerancang dan mengimplementasikan sebagian besar sistem software, dengantidak memiliki petunjuk dan latihan teknis yang cukup.

. Para lulusan program komputer science pada sebagian besar universitas yangbelum pemah mengenal Rekayasa Perangkat Lunak, yang tidak menggunakanteknik dan piranti dalam membuat produk software yang berkualitas tinggi.

Banyak program komputer science yang tidak memberikan pelajaran RekayasaPerangkat Lunak, bila mereka memberikannya pelajaran tersebut bersifat pilihandan 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 secarakeseluruhan dapat memenuhi kebutuhan pemakai.

Produk software memiliki banyak bagian yang meliputi manual, referensi,tutorial, instruksi instalasi, data sampel, pelayanan pendidikan, pelayananpendukung teknis dan sebagainya. Para insinyur software menghasilkan produksoftware, bukan hanya software.

Semua yang dihasilkan oleh proyek software adalah produk kerja (workproduct). Produk kerja meliputi (1) Dokumen engineering yang dipakai untukmenentukan, mengontrol, dan memantau usaha kerja ; (2) Obyek yang dijalankanseperti prototipe, kendali test (test harness), dan piranti pengembangan tujuan

5

Page 6: Bab1

khusus ; dan (3) Data yang digunakan untuk testing, rnelacak proyek dansebagainya.Para insinyursoftwarernernbantumenghasilkansebagianOOsarprodukkerja karena rnereka rnernilikikemarnpuan teknis. Kenyataannya para insinyursoftware sering rnenggunakan waktu yang lama untuk pekerjaan produk kerjanon-software, khususnya dokurnen, daripada rnengerjakanpekerjaan software.

1.5. TIPEDANUKURANPROYEKSOFTWARE

lIuuu.u

.

u

.

...............__......................

6

Proyek software rnerniliki berbagai ukuran. Salah satu cara untukrnenggolongkan ukuran tersebut adalah dengan baris kode seperti dalam taOOI1.1.

KATEGORI UKURAN PROYEKu

~

un---nn n _. _0000

!~~tlll~liil!liii!I~~II:i:ili::!i!ii!~~:lii:iIli:iilillillilll.!'

Tidak pentingKeeil

SedangBesar

Sangat besar

Besar sekali

0-4 Minggu1-6 Bulan

0.5-2 Thn

2-3 Tahun4-5 Tahun

5-10 Tahun

Utilitas pendek

Pustaka fungsi

Produksi Compiler C

Sistem Operasi keeil

Sistem Operasi besar

Sistem switching

Proyek software yang paling besar ini memerlukan ribuan programer, manajerdan personal pendukung. Fungsi dan me sistern jumlahnya .puluhan dari ribuan

dan dapat didistribusikan. ke banyak rnesin. Perubahan yang dilakukan terhadapsebuah file dapat rnengakibatkan ratusan file lainnya - dan sernua orang yangOOkerjadengan file-file tersebut. Inilah kerumitan pada hubungan intern diantarasernua elernen sistern ini yang rnernbedakan Rekayasa Perangkat Lunak. Kasusini akan sulit bagi rnereka yang OOlurnpernah OOkerjadilingkungan proyek besar,untuk rnenerirna kerumitan tersebut. Ini adalah salah satu penghalang dalampengajaran Rekayasa Perangkat Lunak.

Page 7: Bab1

Mereka yang telah faham dengan teknik Rekayasa Perangkat Lunak untukproyek keeil mungkin mengira bahwa teknik tersebut akan cukup bila dipakaiuntuk proyek besar. Pendapat ini biasanya tidaklah benar misalnya piranti RekayasaPerangkat Lunak kadang-kadang tidak dapat dipakai untuk sistem terdistribusi.Teknik manajemen perubahan informal untuk kelompok yang terdiri dari limapembuat program tidak dapat dipakai untuk kelompok yang berjumlah 50 orang.

Praktek Rekayasa Perangkat Lunak merupakan hal yang penting untuk proyekpada semua ukuran. Untuk proyek yang sangat besar dan besar sekali praktektersebut sangat diperlukan karena sistem yang berukuran besar seperti ini tidakakan dapat dibuat tanpa diadakannya praktek diatas. Terdapat bukti empiris bahwaukuran proyek memiliki pengaruh yang besar pada atribut proyek penting sepertiproduktifitas programer individual, yang menurun drastis pada saat ukuran timpengembangan dan sistem meningkat. Akibat ini disebabkan karena kurangnyakoordinasi dan komunikasi pada proyek besar. Conte dan kawan-kawanmemberikan pembahasan yang menarik tentang studi empiris dari faktor yangmempengaruhi proyek software.

Faktor lain yang disebabkan oleh ukuran proyek adalah jumlah dokumentasiyang diperlukan. Sebagai contoh proyek yang tidak penting misalnya programmetrik kode sumber yang sederhana seperti account, mungkin tidak memerlukandokumen engineering apapun, dan tidak memerlukan dokumentasi pemakai yanglebih banyak selain halaman manual. Namun sebaliknya, proyek berukuran sedang,seperti compiler C, hendaknya memiliki satu set dOkumen engineering yangpaling tidak meliputi eksplorasi konsep dan dokumen kelayakan, dokumenpersyaratan, rencana proyek, dokumen disain, test plan, dan ringkasan proyek.Paling tidak pemakai memerlukan manual, tutorial, kartu referensi cepat, instruksiinstalasi dsb.

Merupakan hal yang tidak berguna bila kita menuntut dokumentasi utilitasmetrik sebanyak compiler C tersebut. Namun demikian tuntutan semacam inikadang-kadang dapat terpenuhi. Hal ini merupakan contoh yang umum tentangpraktek 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 substansialberbeda untuk program sistem operasi, program aplikasi keilmuan, program aplikasi.bisnis serta sistem real-time. Perbedaan produktifitas diantara proyek softwareyang berbeda telah di obsevasi. Praktek-praktek Rekayasa Perangkat Lunak harusdisesuaikan 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

Page 8: Bab1

yang tepat untuk sebuah proyek bukanlah hal yang mudah. Pimpinan insinyursoftware hams membentukmetodologiproyek dengan memilihdari berbagai alatteknik dan metode yang ada yang sesuai untuk proyek mereka.

1.6. TAHAP-TAHAPPEMBUATANSOFTWARESERTAMODELNYA

Metodologi proyek diterapkan dalam konteks tahap-tahap pengembangansoftware (software ~ivecycle) - urut-urutan tahap pengembangan, yang disebutfase, yang merupakan tahapan yang hams dilalui oleh produk software dari konsepawal sampai tahap terakhir. Model tahap-tahap tersebut merupakan penyajiandari tahap-tahap pengembangan software yang juga dapat berisikan alur informasi,saat penentuan keputusan dsb. Kita menekankan bahwa model tahap-tahap tersebuthanyalah merupakan model. Tidak ada proyek sesungguhnya yang berlaku secaratepat sebagaimana yang ditunjukkan oleh suatu model dan penyimpangan iniakan banyak.

Fase-fase dari model tahapan penyusunan dapat merupakan fase temporal-yang membentuk urutan dalam waktu - atau fase logis - yang menunjukkantahap-tahap bukan rriembentuk urutan temporal. Sebagai contoh impleroentasisecara logis akan mendahului pepguj,ian namun bagian fase implementasi danpengujian dapat terjadi secara serempak. Jadi model tahapan yang menggunakanfase logis dapat memiliki fase implementasi sebelum fase pengujian, sedangkanmodel yang menggunakan fase temporal mungkin fase-fase ini akan bertumpangtindih. Model tahapan ini dapat digunakan secara tertulis untuk memberikantugas pada kejadian tahapan pengembangan atau secara deskriptif untuk merecordperistiwa-peristiwa pada tahapan tersebut. Banyak model tahap pengembangansistem yang telah diajukan. Sebagian besar model-model tersebut memilikikesamaan pada tahap-tahap fundamental, tetapi berbeda dalam hal terminologi,penekanan, keluwesan dan cakupannya.

Model temporal prekriptif yang rinci bermanfaat dalam suatu rencana proyekkarena model ini memetakan jalannya proyek yang dikehendaki. Model temporaldeskriptifbermanfaat dalam pelaksanaan dokumentasi tahap-tahap pengembanganserta dalam menganalisa proyek bila telah selesai.

Model tahapan pengembangan yang kita pakai dalam buku ini adalah modellogis preskriptif umum. Model ini bersifat umum karena hanya memberikan

8

Page 9: Bab1

urutanJogis tentang fase-fase pengembangan. Meskipun model ini akan lebihbaik untuk menyajikantemporal khusus namun tidak ada model seperti ini yangdapat untuk semua proyek software. Seperti bagian-bagian lain dari metodologisoftware, model tahap pengembangankhusus harus dibentuk untuk proyek soft-ware khusus.

Model kita adalah model air terjun ( waterfall ) standard yang berisikanfase-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 menyebutkanapa yang akan dilakukan oleh sistem yang diproyeksikan, unsur apa yangakan diperlukan oleh produk software serta karakteristik apa yang harusdimiliki oleh unsur produk.. Fase disain. Mendisain sistem dan mendokumentasikansistem. Dokumen

disain menentukan eara pembuatan sistem software untuk memenuhipersyariltantersebut.

. Fase implementasi.Menulis software.

. Fase pengujian.Meneobasoftwareuntuk mengetahuiapakahtelah memenuhipersyaratannya.

. Fase perawatan.Mengikutipenempatanproduk software.membetulkankesalahan; mengubah dan memperluas sistem.

Model ini seperti model lainnya hanya memberikan cara yang sebenarnyadikerjakan oleh suatu proyek ( gambar 1.1 )..

Sangat banyak hal yang tidak dlramalkan terjadi pada proyek software untuksemua model yang lebih banyak daripada petunjuk umum. Model waterfall seringdikritik karena hanya sedikit yang sama dengan kenyataan proyek. Namun modelini merupakan model yang banyak dipakai dalam proyek besar. Lebih lanjutmodel ini bermanfaat bagi segi pedagogis, itulah sebabnya kita menggunakanmodel tersebut.

1.7 ATRIBUTKUALITASSOFTWARE

Kualitas dihubungkan dengan pemenuhan tuntutan pemakai. Salah satu earamenghubungkan kualitas dengan pemakai adalah dengan mengikuti Juran dalam

9

Page 10: Bab1

mendefinisikankuaIitas sebagai (kecocokan penggunaan). Juran membedakandua aspek keeocokan penggunaan: Koleksikemampuan produk yang memenuhituntutan pemakai dan bebas dari kekurangan. Sebuah produk dengan koleksikemampuan yang dapat memenuhi tuntutan pemakai maka dapat memberikankepuasan pembeli. Terbebas dari kekurangan dapat menghindari ketidakpuasanpembeli. Kedua aspek ini dapat memenuhi tuntutan pemakai ( kualitas tinggi ).

Concept exploretlonand

feasibility ene'ysls

Gambar 1.1

Model pengembangan software waterfall.

KuaIitas produk software yang telah selesai terutama tergantung pada kuaIitasproduk kerja yang dihasilkan selama pengembangan dan perawatan. PengertiankuaIitas sebagai fitness for use menghasilkan atribut untuk mengevaIuasi kuaIitasproduk kerja yang berdasarkan pada tuntutan pemakai dari produk tersebut.Misalnya, dokumen spesifikasi tuntutan dipakai oleh pembeli dan pembuat untukmerecord keputusan dan persertujuan tentang.produk .yang akan dibuat, olehdisainer sebagai sumber definitif tenteng informasi produk yang. akan didisain,bagi dokumenter merupakan sumber informasi tentang eara kerja produk tersebutserta earn pemakaiannya, bagi penguji merupakan sumber informasi tentang earnsistem tersebut berlaku hubungannya untuk meneoba data, dan tentang parameterunjuk kerja. Tuntutan ini memberikan motifasi pada atribut kuaIitas khusus untuk

10

Page 11: Bab1

dokumen spesiftkasi tuntutan- 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 seearatepat dapat menjelaskan fungsi dan kekayaan yang diperlukan oleh suatuproduk; Softwaredikatakanbenarjika telah memenuhipersyarataninput danoutputnya; dokumentasi program dikatakan betul bila secara akurat dapatmenjelaskan program.

. Eftsien.Atributinimenunjukkantentangearapemakaiansumberkomputasisecara baik. Sebagai eontoh, Quietsort lebih eftsien daripada Bubblesort sebabdidapat melakukan sort daftar dengan instruksi mesin yang lebih sedikit.

. Perawatan. Atribut ini dapat diterapkan untuk semua produk keIja tapi sebagianbesar sering diaplikasikan untuk software. Perawatan ini menunjukkan betapamudahnya eara melakukan perbaikan, perubahan atau perluasan.

. Mudah dipindahkan (Portable). Atribut ini menunjukkan betapa mudahnyasoftware dapat dipindah tergantung dari jenis lingkungan.

. Mudah dibaea (Readable). Atribut ini berlaku untuk semua produk kerjatekstual atribut ini menunjukkan betapa mudahnya kita memahami produkkerja.

. Dapat dipereaya (Reliable).Atribut ini biasanyaberlakuunlJk software serta'mengaeu pada kemampuan software untuk dijalankan sesuai denganpermintaan untuk periode pemakaian tambahan.

. Dapatdipakailagi (Reuseable).Atributinibiasanyaditerapkanpadaperangkatlunak dan berkaitan dengan seberapa baik program dapat melanjutkanoperasinya seeara betul dalam mengatasi masukkan yang salah.

. Kuat (Rebost).Atribut ini untuk software serta mengaeueara suatu programmeneruskan operasinya dengan benar.

. Dapat di uji (Testable).Atribut ini menunjukbetapa mudahnyaproduk kerjadieoba seeara penuh, akurat, efisien dan sistimatisuntuk mengetahuiapakahdia memenuhi persyaratan.

. Memilikidokumentasiyangbaik(Welldokumented).Atributinimenunjukkanbetapa baiknyaproduk softwaredidukungoleh materialyang seeara lengkapmenjelaskan instalasinya, operasi, perawatan, perbaikan, pengembangan,konstruksi dan evolusi.

11

Page 12: Bab1

Atribut kualitas memiliki hubungan yang kompleks. Misalnya kode yangsangat dioptimalkan sering padat tapi sukar dibaca. Kode yang sukar dibacabiasanya perawatannya kurang. Sebaliknya kode yang dioptimalkan biasanyalebih efisien.

Progamer dapat meningkatkan atribut kualitas tertentu pada programnya,meskipun biasanyamengorbankanbagian yang lain. Para insinyur software hamsmemutuskan atribut kualitas mana yang paling penting untuk proyek mereka.Misalnya, bila sebuah sistem diharapkan dapat tahan lama maka kemampuanperawatandapat merupakanhal yang terpenting,sedangkanefisiensidapat bersifatkurang penting. Teknik standard dan praktek Rekayasa Perangkat Lunak dapatdipakai untuk mempromosikan perawatan dan portabilitas, meskipun mungkinmengorbankan efisiensi. Pembahasan ini sekali lagi menunjukkan arti pentingdan kesulitan dalam menentukan metodologi proyek yang tepat.

12