TENTANG PROSES (PADNANGAN UMUM)

2.1. MODEL PROSES PERANGKAT LUNAK

Jadi model proses merupakan suatu deskripsi yang disederhanakan dari

proses perangkat lunak dan kemudian dipresentasikan dengan sudut pandang
tertentu. Model proses ini bisa saja mencakup suatu kegiatan yang termasuk
dalam bagian dari proses perangkat lunak tersebut dan produk perangkat lunak.
Serta terlibatnya peran seseorang pada rekayasa perangkat lunak tersebut.

Model proses perangkat lunak itu sendiri dibagi menjadi beberapa macam
pengembangan, seperti dibawah ini :

1. Waterfall

Pengertian model waterfall ini adalah suatu model klasik yang me miliki
pengembangan perangkat lunak secara sistematis. Jadi, dari model waterfall ini
melakukan pengerjaan dari suatu sistem dilakukan secara berurutan atau secara
linear.

Kelebihan dari waterfall:

1
  Software yang dikembangkan dengan metode ini biasanya
menghasilkan kualitas yang baik.
 Dokumen pengembangan sistem sangat terorganisir. Mengapa? Karena
pada setiap fasenya harus terselesaikan secara lengkap sebelum
nantinya akan melangkah ke fase berikutnya.

Kekurangan dari waterfall:

 Perubahan sulit dilakukan karena sifatnya yang kaku. Jadi, karena sifat
kakunya inilah model proses waterfall mungkin cocok ketika nanti
kebutuhan yang dikumpulkan lengkap, sehingga perubahan bisa
ditekan sekecil mungkin. Tapi pada kenyataannya jarang sekali
pengguna yang bisa memberikan kebutuhan secara lengkap, mungkin
karena perubahan kebutuhan adalah sesuatu yang wajar terjadi.

2. Prototype

Metode Prototype merupakan metode pengembangan perangkat lunak yang

memodelkan dari sistem kerja suatu perangkat lunak yang belum lengkap dari
pihak user.

Kelebihan dari prototype :

 User dapat berinteraksi aktif.

 Penentuan kebutuhan lebih mudah diwujudkan.
 Mempersingkat waktu pengembangan.

Kekurangan dari prototype :

 Proses analisis dan perancangan terlalu singkat.

 Mengesampingkan alternatif pemecahan masalah.
 Bisanya kurang fleksible dalam mengahadapi perubahan.
 Prototype yang dihasilkan tidak selamanya mudah dirubah.
 Prototype terlalu cepat selesai.

3. Spiral

Model spiral adalah model proses dari software yang evolsioner dan dapat
merangkai dengan sifat yang iteraktif dari prototype dengan cara kontrol dan
aspek sistematis dari model sekuensial linear. Model ini sangat berpotensi untuk
pengembangan versi software secara cepat.

2
Kelebihan dari spiral :

 Nantinya dapat disesuaikan agar perangkat lunak bisa digunakan

selama perangkat lunak komputer masih aktif.
 Model ini cocok untuk pengembangan sistem dan perangkat lunak
skala besar.

Kekurangan dari spiral :

 Sulit untuk menyakinkan pelanggan bahwa pendekatan evolusioner ini

bisa dikontrol.
 Memerlukan penaksiran resiko yang masuk akal dan akan menjadi
masalah yang serius jika resiko mayor tidak ditemukan dan diatur.
 Butuh waktu lama untuk menerapkan paradigma ini menuju kepastian
yang absolute.

4. Rapin Aplication Development (RAD)

Model RAD merupakan sebuah adaptasi “kecepatan tinggi” dari model sekuensial
linier, yang di mana perkembangan ini cepat dicapai dengan menggunakan
pendekatan kontruksi berbasis komponen.

Kelebihan dari RAD :

 Setiap fungsi mayor dapat dimodulkan dalam waktu tertentu kurang

dari 3 bulan dan dapat dibicarakan oleh tim RAD yang terpisah dan
kemudian diintegrasikan sehingga waktunya lebih efisien.
 RAD mengikuti tahap pengembangan sistem seperti umumnya, tetapi
mempunyai kemampuan untuk menggunakan kembali komponen yang
ada sehingga pengembang tidak perlu membuat dari awal lagi dan
waktu yang lebih singkat

Kekurangan dari RAD adalah :

 Bagi proyek yang besar tetapi berskala, RAD memerlukan sumber daya
manusia yang memadai untuk menciptakan jumlah tim RAD yang baik.
 RAD menuntut pengembangan dan pelanggan memiliki komitmen di
dalam aktivitas rapid-fire yang diperlukan untuk melengkapi sebuah
sistem, di dalam kerangka waktu yang sangat diperpendek. Jika
komitmen tersebut tidak ada, proyek RAD akan gagal.

3
5. Incremental

Model incremental (Incremental waterfall model) merupakan perbaikan dari

modelwaterfall dan sebagai standar pendekatan top-down. Ide dasar dari model ini
adalahmembangun software secara meningkat (Increment) berdasarkan
kemampuan fungsional.

Kelebihan dari Incremental :

 Penambahan kemampuan fungsional akan lebih mudah diuji,

diverifikasi, dan divalidasi dan dapat menurunkan biaya yang
dikeluarkan untuk memperbaiki sistem.
 Nilai penggunaan dapat ditentukan pada setiap increament sehingga
fungsionalitas sistem disediakan lebih awal.
 Increment awal berupa prototype untuk membantu memahami
kebutuhan pada increment berikutnya.
 Memiliki risiko lebih rendah terhadap keseluruhan pengembagan
sistem.
 Prioritas tertinggi pada pelayanan sistem adalah yang paling diuji.

Kekurangan dari Incremental :

 Tiap bagian tidak dapat diintegrasikan.

 Setiap tambahan yang dibangun harus dimasukkan kedalam struktur
yang ada tanpa menurunkan kualitas dari yang telah dibangun system
tersebut sampai saat ini.
 Penambahan staf dilakukan jika hasil incremental akan dikembangkan
lebih lanjut.

2.2. Pengertian CMMI

CMMI singkatan Capability Maturity Model Integration.CMMI adalah

kerangka praktik terbaik. Versi saat ini, CMMI-DEV, menjelaskan praktik terbaik
dalam mengelola, mengukur dan memonitor proses pengembangan perangkat
lunak. Model CMMI tidak menggambarkan proses itu sendiri; menggambarkan
karakteristik proses yang baik, sehingga memberikan pedoman bagi perusahaan
mengembangkan atau mengasah set mereka sendiri proses.

4
CMMI (Capability Maturity Model Integration) merupakan suatu model untuk
meningkatkan suatu proses dalam organisasi atau perusahaan. Proses ini
melibatkan 2 komponen lainnya yaitu orang dan teknologi.

Dengan meningkatkan proses yang dinilai berdasarkan model CMMI pada suatu
perusahaan atau organisasi, maka CMMI akan bermanfaat untuk memperbaik
prediksi jadwal dan budget, waktu siklus, kualitas, moral pegawai, meningkatkan
produktivitas.

Asal Mula CMMI

CMMI adalah penerus CMM (Capability Maturity Model). Kedua CMM dan
CMMI dikembangkan di Software Engineering Institute (SEI) di Carnegie Mellon
University di Pittsburgh, Pa. CMM dikembangkan pada akhir 1980-an, dan
pensiun satu dekade kemudian ketika CMMI dikembangkan. CMMI v1.02 dirilis
pada tahun 2000.

Fungsi Dan Tujuan CMMI

Komersial dan organisasi pemerintah menggunakan model CMMI untuk

membantu dalam menentukan perbaikan proses untuk rekayasa sistem, rekayasa
perangkat lunak, dan produk terpadu dan pengembangan proses.

Organisasi menggunakan proses untuk membantu mereka mengembangkan,

memperoleh dan mempertahankan produk dan jasa, dan untuk benchmark diri
terhadap orang lain. proses yang lebih baik dapat berarti biaya yang lebih rendah
dan hasil kualitas yang lebih baik, serta perkiraan waktu yang lebih realistis untuk
proyek-proyek.

Namun, seperti kerangka apapun, CMMI bukan perbaikan cepat untuk semua
yang Sakit sebuah organisasi pembangunan. SEI memperingatkan bahwa proyek-
proyek perbaikan kemungkinan akan diukur dalam bulan dan tahun, tidak hari dan
minggu. Karena mereka biasanya memiliki lebih banyak pengetahuan dan sumber
daya, organisasi yang lebih besar mungkin menemukan mereka mendapatkan
hasil yang lebih baik, tetapi perubahan proses CMMI juga dapat membantu
perusahaan kecil.

SEI tidak menawarkan sertifikasi bentuk apapun (siapa pun yang memberitahu
Anda sebaliknya akan berbohong, mungkin untuk keuntungan). Ini hanya lisensi
dan kewenangan penilai memimpin untuk melakukan penilaian. Perusahaan dapat
melaporkan hasil mereka pada penilaian yang diterbitkan situs, tetapi tidak wajib.

5
SEI bermaksud model dan metode penilaian untuk digunakan dalam perbaikan
diri, untuk membantu meningkatkan tingkat kualitas produk dan membantu
perusahaan dalam memprediksi lebih baik waktu dan anggaran yang dibutuhkan
untuk mengembangkan mereka. Model membantu menciptakan lingkungan yang
mendukung fungsi-fungsi ini dengan cara yang berulang. perbaikan terus-menerus
dibangun ke dalam model.

Mendapatkan nilai terbesar dari mengadopsi proses model 'melibatkan tiga

komponen utama:

Memahami praktek baru

Tidak memperlakukan mereka sebagai terukir di batu, tapi beradaptasi mereka

untuk lingkungan

Menempel dengan perubahan yang cukup lama bagi mereka untuk membuat
perbedaan

Sebuah penilaian resmi dapat memberikan perusahaan sebuah ide dari

kematangan proses, dan membantu membuat peta jalan menuju perbaikan. Setelah
semua, Anda tidak dapat merencanakan rute ke tujuan jika Anda tidak tahu di
mana Anda saat ini. Organisasi dapat menyesuaikan penggunaan model untuk
memenuhi kebutuhan mereka sendiri dan kebutuhan proyek tertentu. SEI
mengatakan bahwa model:

Panduan upaya perbaikan proses dan organisasi bantuan menetapkan dan

mencapai tujuan perbaikan.

Memberikan bahasa yang umum untuk komunikasi lintas organisasi dan

benchmarking.

Memberikan mengintegrasikan, mengorganisir kerangka kerja untuk usaha

organisasi.

Membantu organisasi memahami praktek apa yang khusus untuk melakukan,

bagaimana meningkatkan kemampuan dalam melakukan praktek tersebut, dan
proses apa daerah untuk fokus pada berikutnya.

Organisasi juga dapat menggunakan hasil penilaian untuk pemilihan sumber atau
verifikasi dari tingkat kematangan organisasi lain.

6
SEI memberikan laporan tentang perbaikan kinerja untuk memberikan calon
pengguna model gagasan tentang perbaikan beberapa telah dicapai. Misalnya,
salah satu organisasi melaporkan bahwa mencapai CMMI tingkat kematangan 3
memungkinkan untuk mengurangi biaya dari ulang oleh 42 persen selama
beberapa tahun, dan lain menggambarkan 5: ROI 1 untuk kegiatan kualitas dalam
CMMI tingkat kematangan 3 organisasi. SEI menyediakan beberapa deskripsi
perbaikan terukur yang dapat Anda jelajahi.

CMMI, untuk semua kekuatan, tidak sesuai dengan setiap organisasi. Seperti
halnya kerangka kerja atau metodologi, pelaksanaannya sering gagal, belum tentu
karena kelemahan dalam konsep, tetapi karena misfires eksekusi organisasi.

Masalah dapat budaya. Misalnya, CMMI telah disebut "mati oleh proses." Jika
orang-orang Anda tidak sudah sangat berorientasi proses, CMMI kemungkinan
tidak cocok tanpa pelatihan yang ekstensif (dan mungkin beberapa penyesuaian
sikap). Mencoba untuk overlay CMMI pada proses yang ada tanpa terlebih dahulu
melakukan analisis gap untuk melihat apakah ada fit bisa menjadi resep bagi
kegagalan. Juga, kritikus mengeluh bahwa CMMI (seperti CMM sebelum)
menuntut banyak dokumentasi dari pengguna.

Mendapatkan belum tentu ada setengah menyenangkan, baik. Penilaian dan

konsultan bisa sangat mahal. SEI mengatakan bahwa tim penilai terdiri dari 4-9
anggota (yang masing-masing dapat biaya lebih dari $ 1.000 per hari). Dan
penilaian, seperti Roma, tidak dibangun dalam satu hari atau bahkan dua atau tiga.
Tim tidak hanya chatting dengan beberapa orang atau melihat satu proyek; itu
melakukan pemeriksaan serius dari beberapa proyek.

7
2.3. POLA TAHAPAN-TAHAPAN REKAYASA PERANGKAT LUNAK

Seperti telah disebutkan, meskipun dalam pendekatan berbeda-beda,

namun model-model di atas memiliki kesamaan, yaitu menggunakan pola tahapan
analysis – design – coding (construction) – testing – maintenance.

1. Analisis

Analisis sistem adalah sebuah teknik pemecahan masalah yang menguraikan

sebuah sistem menjadi komponen-komponennya dengan tujuan mempelajari
seberapa bagus komponen-komponen tersebut bekerja dan berinteraksi untuk
meraih tujuan mereka.

Analisis mungkin adalah bagian terpenting dari proses rekayasa perangkat lunak.
Karena semua proses lanjutan akan sangat bergantung pada baik tidaknya hasil
analisis. Ada satu bagian penting yang biasanya dilakukan dalam tahapan analisis
yaitu pemodelan proses bisnis.

Model proses adalah model yang memfokuskan pada seluruh proses di dalam
sistem yang mentransformasikan data menjadi informasi (Harris, 2003). Model
proses juga menunjukkan aliran data yang masuk dan keluar pada suatu proses.
Biasanya model ini digambarkan dalam bentu Diagram Arus Data (Data Flow
Diagram / DFD). DFD meyajikan gambaran apa yang manusia, proses dan
prosedur lakukan untuk mentransformasi data menjadi informasi.

External Entity melambangkan sumber data (dari mana data berasal) atau
penerima informasi (tujuan akhir dari data). Contoh external entity antara lain
konsumen yang memesan suatu produk, manajer yang mengevaluasi laporan
penjualan mingguan, dan lain-lain.

8
Proses adalah serangkaian langkah yang dilakukan untuk memanipulasi data,
misalnya pengumpulan, pengurutan, pemilihan, pelaporan, peringkasan, analisis
dan lain-lain.

Data store adalah tempat untuk menyimpan data untuk digunakan kemudian.
Nama yang pada data store ini merupakan abstraksi dari data yang disimpan.
Namun detil / item data apa saja yang ada, bagaimana cara akses, atau bagaimana
mengorganisasinya tidak dijelaskan dalam notasi ini.

Data flow menunjukkan aliran data dari satu tempat ke tempat lain. Perpindahan
data ini dapat dari external entity ke proses, antar proses satu dengan yang lain,
dari proses ke data store. Dalam penggambarannya setiap data flow harus diberi
label yang menunjukkan data apa yang mengalir.

Context diagram adalah DFD ruang lingkup dari sistem yang menunjukkan batas-
batas sistem, external entitiy yang berinteraksi dengan sistem dan aliran data
utama antara external entity dengan sistem. Context diagram menggambarkan
keseluruhan sistem dalam suatu proses tunggal. Pada proses ini diberi notasi
angka 0 untuk menunjukkan ini adalah level paling abstrak dari sistem.

Selain itu ada tiga external entity yaitu customer, kitchen dan restaurant
manager. Ketiganya dapat berperan sebagai sumber data (dalam contoh di atas
adalah customer) atau sebagai penerima informasi (dalam contoh di atas customer,
kitchen, dan restaurant manager).

Data flow yang tampak pada gambar menunjukkan ada satu data flow yang masuk
ke sistem dan ada tiga data flow yang keluar dari sistem. Masing-masing data
flow diberi label yang menunjukkan data apa yang sedang mengalir.

Setelah context diagram terbentuk dengan benar maka langkah selanjutnya adalah
merinci context diagram tersebut dalam DFD Level 0. DFD Level 0 adalah DFD
yang merepresentasikan proses-proses, data flow dan data storage utama di dalam
sistem. DFD Level 0 ini akan digunakan sebagai dasar untuk membangun DFD

9
yang level dibawahnya (Level 1, 2, 3, .. dst) atau biasa disebut sebagai
dekomposisi DFD.

Masing-masing proses diberi nomor kode 1.0, 2.0, 3.0 dan 4.0. Jumlah external
entity harus tetap yaitu 3 demikian puladata flow yang keluar dan masuk (input
dan output) ke dalam sistem harus sama dengan pada context diagram. Sedangkan
data flow yang berada di dalam sistem (yang mengalir antar proses dan atau data
storage) tergantung pada proses dan data storage yang terlibat.

Ada dua data storage yaitu Goods Sold File dan Inventory File. Kedua data
storage ini digunakan untuk menyimpan data dari suatu proses. Data ini juga akan
dibaca / diakses oleh proses yang lain. Sebagai contoh data storage Inventory File
berisi data hasil proses 3.0(Update Inventory File). Data ini akan digunakan
proses 4.0 (Produce Management Reports) untuk membuat laporan yang akan
disampaikan pada Restaurant Manager.

DFD level berikutnya yaitu level 1, 2 dan seterusnya diperlukan apabila level
sebelumnya dirasa kurang detil. Sebagai contoh apabila DFD level 0 (Gambar
14.12) dirasa belum cukup detil menunjukkan arus data yang mengalir, maka
dapat dibuat detilnya pada DFD level 1.

Bagian yang harus didetilkan biasanya adalah proses. Detil pada level berikutnya,
mungkin pada semua proses atau hanya pada proses-proses tertentu saja. DFD
pada level 0 maupun level di bawahnya memiliki kesamaan aturan yang tersaji.

2. Disain

Disain perangkat lunak adalah tugas, tahapan atau aktivitas yang difokuskan pada
spesifikasi detil dari solusi berbasis computer (Whitten et al, 2004). Disain
perangkat lunak sering juga disebut sebagai physical design. Jika tahapan analisis
sistem menekankan pada masalah bisnis (business rule), maka sebaliknya disain
perangkat lunak fokus pada sisi teknis dan implementasi sebuah perangkat lunak
(Whitten et al, 2004).

10
Output utama dari tahapan disain perangkat lunak adalah spesifikasi disain.
Spesifikasi ini meliputi spesifikasi disain umum yang akan disampaikan kepada
stakeholder sistem dan spesifikasi disain rinci yang akan digunakan pada tahap
implementasi. Spesifikasi disain umum hanya berisi gambaran umum agar
stakeholder sistem mengerti akan seperti apa perangkat lunak yang akan
dibangun.

Biasanya diagram USD tentang perangkat lunak yang baru merupakan point
penting dibagian ini. Spesifikasi disain rinci atau kadang disebut disain arsitektur
rinci perangkat lunak diperlukan untuk merancang sistem sehingga memiliki
konstruksi yang baik, proses pengolahan data yang tepat dan akurat, bernilai,
memiliki aspek user friendly dan memiliki dasar-dasar untuk pengembangan
selanjutnya.

Desain arsitektur ini terdiri dari desain database, desain proses, desain user
interface yang mencakup desain input, output form dan report, desain hardware,
software dan jaringan. Desain proses merupakan kelanjutan dari pemodelan
proses yang dilakukan pada tahapan analisis.

3. Konstruksi

Konstruksi adalah tahapan menerjemahkan hasil disain logis dan fisik ke dalam
kode-kode program computer. Buku ini sebagian besar berisi tentang bagian ini.

4. Pengujian

Pengujian sistem melibatkan semua kelompok pengguna yang telah direncanakan

pada tahap sebelumnya. Pengujian tingkat penerimaan terhadap perangkat lunak
akan berakhir ketika dirasa semua kelompok pengguna menyatakan bisa
menerima perangkat lunak tersebut berdasarkan kriteria-kriteria yang telah
ditetapkan.

5. Perawatan dan Konfigurasi

11
Ketika sebuah perangkat lunak telah dianggap layak untuk dijalankan, maka
tahapan baru menjadi muncul yaitu perawatan perangkat lunak.

a. Tipe perawatan corrective dilakukan jika terjadi kesalahan atau biasa dikenal
sebagai bugs. Perawatan bisa dilakukan dengan memperbaiki kode program,
menambah bagian yang dirasa perlu atau malah menghilangkan bagian-bagian
tertentu.

b. Tipe perawatan routine biasa juga disebut preventive maintenance dilakukan

secara rutin untuk melihat kinerja perangkat lunak ada atau tidak ada kesalahan.

c. Tipe perawatan sistem upgrade dilakukan jika ada perubahan dari komponen-
komponen yang terlibat dalam perangkat lunak tersebut. Sebagai contoh
perubahan platform sistem operasi dari versi lama ke versi baru menyebabkan
perangkat lunak harus diupgrade

Kualitas atau biasa disebut sebagai mutu adalah tentang baik buruk nya derajat
sesuatu hal. Kualitas adalah salah satu hal yang harus diperhitungkan dalam
berbagai proses ataupun tehnik bisnis. Bahkan seorang sosok visionaris dunia
yaitu Steve Jobs pernah menyampaikan bahwa :

"Quality is more important than quantity. One home run is much better than two
doubles".

Padahal home run dengan doubles itu dalam permainan baseball adalah hal
yang sama dari sisi point. Namun bagi penonton atau penggemar 2 hal itu
memiliki nilai yang berbeda dari kenikmatan menonton pertandingan. Begitu pula
dalam pengembangan software, kualitas merupakan suatu hal yang sangat
penting. namun sulit untuk menentukan seberapa besar kualitas sebuah software.
Hal itu disebabkan oleh beberapa hal seperti :

1. Sulitnya menulis dengan lengkap spesifikasi sebuah perangkat. Misalkan

menginginkan sebuah software yang aman, sejauh mana keamanan tersebut tidak
dapat dituliskan

2. Dalam spesifikasi adanya kesenjangan antara stakeholder. Sehingga

kenyamanan masing masing sulit untuk diukur. Misalkan dalam suatu perusahan
terdapat bagian IT nya yang merasa nyaman terhadap software , namun belum
tentu atasan merasa nyaman juga menggunakan software.

3. Sulitnya mengukur karakteristik kualitas.

Sehingga dapat disimpulkan dalam menentukan kualitas sebuah software adalah

berdasarkan tergantung penilaian subyektif dari pemakainya.

12
 Dalam penilaian sebuah software yang biasanya diwakili oleh Tim
Manajemen Mutu, sebuah produk dinilai tidak akan pernah memenuhi spesifikasi
, sehingga jika produk "hampir benar" maka itu tergolong software yang dapat
diterima. Selain hal tersebut banyak pula yang harus dipertimbangkan dalam
penilaian kualitas software seperti tujuan software, dokumentasi software,
keandalan software dan lain lain. Kualitas subjektif dari perangkat lunak sistem
sebagian besar didasarkan pada karakteristik non-fungsional.

Menurut Boehm,(1978) menyatakan bahwa ada 15 atribut penentuan

kualitas perangkat lunak yang penting, seperti Keselamatan, Understandability ,
Portabilitas, Keamanan, Testability, Usability, Keandalan, Kemampuan
beradaptasi, Reusability, Ketahanan, Modularity, Efisiensi, Kekokohan,
Kompleksitas, dan Learnability. Semua atribut ini tidak memungkin kan bisa
diopltimalkan semua, misalkan kita meningkatkan ketahanan bisa saja fungsi yang
lain melemah akibat peningkatan ketahanan. Sehingga perlu mendefinisikan
kualitas terpenting dalam sebuah perangkat lunak.

2.4. MODEL PROSES PERSONAL DAN MODEL PROSES TIM

1.Proses Perangkat Lunak Pribadi

· Perencanaan (Planning): Aktivitas ini bertujuan untuk mengisolasi spesifikasi

kebutuhan dan mengembangkan baik prakiraan yang berkaitan ukuran perangkat
lunak maupun sumber daya yang diperlukan untuk mengembangkannya.

· Perencanaan peringkat tinggi: Spesifikasi eksternal untuk masing-masing

komponen yang akan dekonstruksi dikembangkan dan suatu rancangan yang
berkaitan dengan pembentukan komponen dibuat.

· Pengembangan: Rancangan peringkat komponen diperhalus dan

· Pengembangan: Rancangan peringkat komponen diperhalus dan ditinjau ulang.

· Postmortem : Menggunakan pengukuran-pengukuran dan metrik-metrik yang

terkumpul dan tingkat efektifvitas ditentukan.

2.Proses Perangkat Lunak Tim

13
Sasaran dari proses tim ini adalah mengembangkan suatu tim atau proyek
perangkat lunak yang mampu mengatur dirinya sendiri untuk menghasilkan
perangkat lunak yang berkualitas tinggi.

2.5. TUJUAN REKAYASA PERANGKAT LUNAK

Secara umunmm tujuan RPL tidak berbeda dengan bidang rekayasa yang lain. Hal
ini dapat kita lihat pada Gambar di bawah ini.

Gambar Tujuan RPL

Dari Gambar di atas dapat diartikan bahwa bidang rekayasa akan selalu berusaha
menghasilkan output yang kinerjanya tinggi, biaya rendah dan waktu penyelesaian
yang tepat. Secara leboih khusus kita dapat menyatakan tujuan RPL adalah:

 memperoleh biaya produksi perangkat lunak yang rendah

 menghasilkan pereangkat lunak yang kinerjanya tinggi, andal dan tepat
waktu
 menghasilkan perangkat lunak yang dapat bekerja pada berbagai jenis
platform
 menghasilkan perangkat lunak yang biaya perawatannya rendah

14