BAB 1
PENGANTAR RPL
Rekayasa perangkat lunak merupakan sebuah
disiplin ilmu yang bertujuan mengembangkan sistem perangkat lunak yang efektif
dari segi biaya. Perangkat lunak bersifat abstrak dan tidak nyata. Rekayasa
perangkat lunak masih merupakan disiplin yang relatif muda. Istilah rekayasa
perangkat lunak pertama kali diajukan pada tahun 1968.
1.1 PENGERTIAN RPL
Banyak orang menyamakan istilah perangkat lunak
dengan program komputer. Sesungguhnya pandangan ini terlalu dangkal, perangkat
lunak tidak hanya mencakup program, tetapi juga semua dokumentasi dan
konfigurasi data yang berhubungan (Sommerville, 2003). Rekayasa perangkat lunak
adalah disiplin ilmu yang membahas semua aspek produksi perangkat lunak, mulai
dari tahap awal spesifikasi sistem sampai pemeliharaan.
Di sisi lain terdapat istilah yang juga tidak
kalah populer adalah computer science atau ilmu komputer.
Pada intinya computer science
berhubungan dengan teori dan metode yang mendasari sistem komputer dan
perangkat lunak. Sedangkan rekayasa perangkat lunak berhubungan dengan
masalah-masalah praktis dalam memproduksi perangkat lunak. Pengetahuan tetang computer science sangat penting bagi
perekayasa perangkat lunak sama seperti pengetahuan tentang fisika sangat
penting bagi teknik kelistrikan.
Istilah lain yang juga populer adalah rekayasa
sistem atau rekayasa sistem berbasis komputer. Rekayasa sistem berhubungan
dengan pengembangan perangkat keras, perancangan kebijakan dan proses, dan
penyebaran sistem sebagaimana pada rekayasa perangkat lunak. Rekayasa sistem
merupakan disiplin yang lebih tua dari rekayasa perangkat lunak.
1.1.1
Product
Saat ini perangkat lunak memiliki dua peran. Peran pertama berfungsi sebagai sebuah produk
dan peran kedua sebagai kendaraan yang mengantarkan sebuah produk (Pressman,
2002). Sebagai produk perangkat lunak
mengantarkan potensi perhitungan yang dibangun oleh perangkat lunak komputer.
Tidak peduli apakah perangkat lunak ada dalam telepon seluler, dalam mainframe
komputer. Perangkat lunak merupakan transformer
informasi yang memproduksi, mengatur, memperoleh, memodifikasi, menampilkan
atau menyebarkan informasi dimana pekerjaan ini dapat menjadi sederhana suatu
bit tunggal atau sekompleks simulasi multimedia. Sebagai kendaraan yang dipakai
untuk mengantarkan produk, perangkat
lunak berlaku sebagai dasar untuk kontrol komputer (sistem operasi), komunikasi
informasi (jaringan komputer).
Untuk memperoleh pemahaman tentang perangkat
lunak serta pemahaman tentang rekayasa perangkat lunak penting juga untuk
mengetahui karakteristik yang membuat perangkat lunak berbeda dengan dengan
produk lain yang dihasilkan oleh manusia. Ketika perangkat lunak dibuat proses
kreatif manusia (analisis, desain, konstruksi dan pengujian) diterjemahkan ke
dalam bentuk fisik.
1.1.2 Process
Proses perangkat lunak merupakan serangkaian
kegiatan dan hasil-hasil relevan yang menghasilkan perangkat lunak. Kegiatan-kegiatan ini sebagian besar dilakukan
oleh perekayasa perangkat lunak. Ada empat kegiatan proses dasar perangkat
lunak:
1)
Spesifikasi
perangkat lunak, fungsional perangkat lunak dan batasan kemampuan operasinya
harus didefinisikan.
2)
Pengembangan
perangkat lunak, perangkat lunak yang memenuhi spesifikasi tersebut harus
dipenuhi.
3)
Validasi
perangkat lunak, perangkat lunak harus divalidasi untuk menjamin bahwa
perangkat lunak melakukan apa yang diinginkan oleh pelanggan.
4)
Evolusi
perangkat lunak, perangkat lunak harus dikembangkan untuk memenuhi kebutuhan
pelanggan yang berubah-ubah.
Proses perangkat lunak yang berbeda mengatur kegiatan
ini dengan cara yang berbeda dan dijelaskan dengan tingkat kerincian yang
berbeda pula. Waktu kegiatan bervariasi, sebagaimana hasilnya.
Proses perangkat lunak sangat rumit dan seperti
semua proses intelektual, bergantung pada penilaian manusia. Karena dibutuhkan
penilaian dan kreatifitas keberhasilan usaha untuk mengotomasi proses perangkat
lunak menjadi terbatas. Satu alasan mengapa otomasi proses memiliki cakupan
terbatas adalah adanya keragaman proses perangkat lunak. Tidak ada proses yang
ideal dan organisasi berbeda yang mengembangkan pendekatan yang benar-benar
berbeda dalam pengembangan perangkat lunak.
1.1.2.1 Model Proses Perangkat Lunak
Model proses perangkat lunak merupakan
deksripsi yang disederhanakan dari proses perangkat lunak yang dipresentasikan
dengan sudut pandang tertentu. Model sesuai sifatnya, merupakan penyederhanaan
sehingga model proses bisa mencakup kegiatan yang merupakan bagian dari proses
perangkat lunak, produk perangkat lunak, peran orang yang terlibat pada
rekayasa perangkat lunak.
1)
Model Air Terjun (Waterfall)
Model ini
dikenal sebagai model air terjun atau siklus hidup pengembangan perangkat
lunak. Model ini dapat dilihat pada Gambar 1.1. Tahap-tahap utama dari model
ini memetakan kegiatan-kegiatan pengembangan dasar, yaitu:
1) Analisis dan Definisi persyaratan.
Pelayanan, batasan dan tujuan sistem ditentukan melalui konsultasi dengan user
sistem. Persyaratan ini kemudian didefinisikan secara rinci dan berfungsi
sebagai spesifikasi sistem.
2) Perancangan sistem dan perangkat
lunak. Proses perancangan sistem membagi persyaratan dalam sistem perangkat
keras atau perangkat lunak. Kegiatan ini menentukan arsitektur sistem secara
keseluruhan. Perancangan perangkat lunak melibatkan identifikasi dan deskripsi
abstraksi sistem perangkat lunak yang mendasar dan hubungan-hubungannya.
3) Implementasi dan pengujian unit.
Pada tahap ini, perancangan perangkat lunak direalisasikan sebagai serangkaian
program atau unit program. Pengujian unit melibatkan verifikasi bahwa setiap
unit telah memenuhi spesifikasi.
4) Integrasi dan pengujian sistem. Unit
program atau program individual diintegrasikan dan diuji sebagai sistem yang
lengkap untuk menjamin bahwa persyaratan sistem telah dipenuhi. Setelah
pengujian sistem, perangkat lunak dikirim kepada pelanggan.
5) Operasi dan pemeliharaan. Biasanya
merupakan fase siklus hidup yang paling lama. Sistem diinstall dan dipakai.
Pemeliharaan mencakup koreksi dan berbagai error yang tidak ditemukan pada
tahap-tahap terdahulu, perbaikan atas implementasi unit sistem dan pengembangan
pelayanan system, sementara persyaratan-persyaratan baru ditambahkan.
Gambar 1.1
Model Waterfall
2)
Model Sekuensial Linier
Gambar 1.2a
menggambarkan sekuensial linier untuk
rekayasa perangkat lunak, yang sering disebut juga dengan “siklus kehidupan
klasik” atau “model air terjun.”
Gambar 1.2a Fase lingkaran pemecahan masalah (Raccoon, 1995)
Gambar 1.2b
Fase-fase di dalam fase lingkaran
pemecahan masalah (Raccoon, 1995)
Gambar 1.3
Model sekuensial linier
Sekuensial
linier mengusulkan sebuah pendekatan kepada perkembangan perangkat lunak yang
sistematik dan sekuensial yang mulai pada tingkat dan kemajuan sistem pada
seluruh analisis, desain, kode, pengujian, dan pemeliharaan. Dimodelkan setelah
siklus rekayasa konvensional, model sekuensial linier melingkupi
aktivitas-aktivitas sebagai berikut:
a) Rekayasa dan Pemodelan Sistem/Informasi
Karena perangkat lunak selalu merupakan
bagian dari sebuah sistem (bisbis) yang lebih besar, kerja dimulai dengan
membangun syarat dari semua elemen sistem dan mengalokasikan beberapa subset
dari kebutuhan ke perangkat lunak tersebut. Pandangan sistem ini penting ketika
perangkat lunak harus berhubungan dengan elemen-elemen yang lain seperti
perangkat lunak, manusia, dan database. Rekayasa dan analisis sistem menyangkut
pengumpulan kebutuhan pada tingkat sistem dengan sejumlah kecil analisis serta
desain tingkat puncak. Rekayasa informasi mencakup juga pengumpulan kebutuhan
pada tingkat bisnis strategis dan tingkat area bisnis.
b) Analisis Kebutuhan Perangkat Lunak
Proses pengumpulan kebutuhan
diintensifkan dan difokuskan, khususnya pada perangkat lunak. Untuk memahami
sifat program yang dibangun, perekayasa perangkat lunak (analis) harus memahami
domain informasi, tingkah laku, unjuk kerja, dan antar-muka (interface) yang diperlukan. Kebutuhan
baik untuk sistem maupun perangkat lunak di dokumentasikan dan dilihat lagi
dengan pelanggan.
c) Desain
Desain perangkat lunak sebenarnya
adalah proses multi langkah yang berfokus pada empat atribut sebuah program
yang berbeda; struktur data, arsitektur perangkat lunak, representasi interface, dan detail (algoritma)
procedural. Proses desain menerjemahkan syarat/kebutuhan ke dalam sebuah
representasi perengkat lunak yang dapat diperkirakan demi kualitas sebelum
dimulai pemunculan kode. Sebagaimana persyaratan, desain didokumentasikan dan
menjadi bagian dari konfigurasi perangkat lunak.
d) Generasi Kode
Desain harus diterjemahkan ke dalam
bentuk mesin yang bisa dibaca. Langkah pembuatan kode melakukan tugas ini. Jika
desain dilakukan dengan cara yang lengkap, pembuatan kode dapat diselesaikan
secara mekanis.
e) Pengujian
Sekali kode dibuat, pengujian
program dimulai. Proses pengujian berfokus pada logika internal perangkat
lunak, memastikan bahwa semua pernyataan sudah diuji, dan pada eksternal
fungsional – yaitu mengarahkan pengujian untuk menemukan kesalahan-kesalahan
dan memastikan bahwa input yang akan memberikan hasil actual yang sesuai dengan
hasil yang dibutuhkan.
f)
Pemeliharaan
Perangkat lunak akan mengalami
perubahan setelah disampaikan kepada pelanggan (perkecualian yang mungkin
adalah perangkat lunak yang dilekatkan). Perubahan akan terjadi karena
kesalahan-kesalahan ditentukan, karena perangkat lunak harus disesuaikan untuk
mengakomodasi perubahan-perubahan di dalam lingkungan eksternalnya (contohnya
perubahan yang dibutuhkan sebagai akibat dari perangkat peripheral atau sistem operasi yang baru), atau karena pelanggan
membutuhkan perkembangan fungsional atau unjuk kerja. Pemeliharaan perangkat
lunak mengaplikasikan lagi setiap fase program sebelumnya dan tidak membuat
yang baru lagi.
Model sekuensial linier adalah
paradigma rekayasa perangkat lunak yang paling luas dipakai dan paling tua.
Tetapi kritik dari paradigma tersebut telah menyebabkan dukungan aktif untuk
mempertanyakan kehandalannya (Hanna, 1995). Masalah-masalah yang kadang–kadang
terjadi ketika model sekuensial linier diaplikasikan adalah:
a) Jarang sekali proyek nyata mengikuti
aliran sekuensial yang dianjurkan oleh model. Meskipun model linier bias
mengakomodasi iterasi, model itu melakukannya dengan cara tidak langsung.
Sebagai hasilnya, perubahan-perubahan dapat menyebabkan keraguan pada saat tim
proyek berjalan.
b) Kadang-kadang sulit bagi pelanggan
untuk menyatakan semua kebutuhannya secara ekplisit. Model linier sekuensial
memerlukan hal ini dan mengalami kesulitan untuk mengakomodasi ketidakpastian
natural yang ada pada bagian awal beberapa proyek.
c) Pelanggan harus bersikap sabar.
Sebuah versi kerja dari program-program itu tidak akan diperoleh sampai akhir
waktu proyek dilalui. Sebuah kesalahan besar, jika tidak terdeteksi sampai
program yang bekerja tersebut dikaji ulang, bias menjadi petaka.
d) Pengembang sering melakukan
penundaan yang tidak perlu. Di dalam analisis yang menarik tentang proyek
actual, (Bradac, 1994) mendapatkan bahwa sifat alami dari siklus kehidupan
klasik membawa kepada blocking state
dimana banyak anggota tim proyek harus menunggu tim yang lain untuk melengkapi
tugas yang saling memiliki ketergantungan. Kenyataannya, waktu yang dipakai
untuk menunggu bisa mengurangi waktu untuk usaha produktif! Blocking state cenderung menjadi lebih
lazim pada awal dan akhir sebuah proses sekuensial linier.
Masing-masing dari masalah tersebut
bersifat riil. Tetapi paradigm siklus kehidupan klasik memiliki tempat yang
terbatas namun penting di dalam kerja rekayasa perangkat lunak. Paradigma itu
memberikan template dimana metode
analisis, desain, pengkodean, pengujian, dan pemeliharaan bisa dilakukan.
Siklus kehidupan klasik tetap menjadi model bagi rekayasa perangkat lunak yang
paling luas dipakai. Sekalipun memiliki kelemahan, secara signifikan dia lebih
baik daripada pendekatan yang sifatnya sembrono kepada pengembangan perangkat
lunak.
3)
Model Prototipe
Sering
seorang pelanggan mendifinisikan serangkaian sasaran umum bagi perangkat lunak,
tetapi tidak melakukan mengidentifikasi kebutuhan output, pemrosesan, ataupun
input detail. Pada kasus yang lain, pengembang mungkin tidak memiliki kepastian
terhadap efisiensi algoritme, kemampuan penyesuaian dari sebuah system operasi,
atau bentuk-bentuk yang harus dilakukan oleh interaksi manusia dengan mesin.
Dalam hal ini, serta pada banyak situasi yang lain, prototyping paradigm mungkin menawarkan pendekatan yang terbaik.
Prototyping paradigma (Gambar 1.4) dimulai dengan
pengumpulan kebutuhan. Pengembang dan pelanggan bertemu dan mendefinisikan
obyektif keseluruhan dari perangkat lunak, mengidentifikasi segala kebutuhan
yang diketahui, dan area garis besar dimana definisi lebih jauh merupakan
keharusan kemudian dilakukan “perancangan kilat”. Perancangan kilat berfokus
pada penyajian dari aspek –aspek perangkat lunak tersebut yang akan Nampak bagi
pelanggan/pemakai (contohnya pendekatan input dan format output). Perancangan
kilat membawa kepada konstruksi sebuah prototype. Prototipe tersebut dievaluasi
oleh pelanggan/pemakai dan dipakai untuk menyaring kebutuhan pengembangan
perangkat lunak. Iterasi terjadi pada saat protipe disetel untuk memenuhi
kebutuhan pelanggan, dan pada saat yang sama memungkinkan pengembang untuk
secara lebih baik memahami apa yang harus dilakukannya.
Mendengarkan
Pelanggan
|
Uji Pelanggan-Mengendalikan Market
|
Membangun Memperbaiki Market
|
Gambar 1.4 Prototipe Paradigma
Secara ideal
prototype berfungsi sebagai sebuah mekanisme untuk mengidentifikasi kebutuhan
perangkat lunak. Bila prototype yang sedang bekerja dibangun, pengembang harus
mempergunakan fragmen-fragmen program yang ada atau mengaplikasikan alat-alat
bantu (contohnya report generator, window manager, dll) yang memungkinkan
program yang bekerja untuk dimunculkan secara cepat.
Tetapi apa
yang kita lakukan dengan prototype tersebut pada saat dia sudah melayani usulan
yang digambarkan di atas? (Brooks, 1975) memberikan jawabannya:
Pada
sebagian besar proyek, system pertama yang dibangun baru saja bisa
dipergunakan. Sistem mungkin terlalu pelan, terlalu besar, janggal di dalam
pemakaian, atau bahkan ketiganya. Tidak ada alternatif lain selain mulai lagi,
tidak dengan halus tetapi dengan lebih halus lagi, dan membangun sebuah versi
yang dirancang kembali di mana masalah-masalah tersebut bisa diselesaikan …
Ketika sebuah konsep system baru atau teknologi baru dipergunakan, seseorang
harus membangun sebuah system sebagai pembuangan, bahkan untuk perencanaan
terbaik sekalipun, tidak akan mudah untuk membuatnya benar pada pertama
kalinya. Dengan demikian, pertanyaan manajemen tidaklah untuk membangun sebuah
system contoh dan untuk membuangnya. Anda akan melakukannya. Satu-satunya
pertanyaan adalah apakah akan merencanakan lebih dulu untuk membangun sebuah
pembuangan, atau menjanjikan untuk menyampaikan pembuangan tersebut kepada
pelanggan …………..
Prototipe
bisa berfungsi sebagai “system yang pertama”. Brooks setuju bila kita
membuangnya. Tetapi mungkin ini merupakan pandangan yang ideal. Memang benar
bahwa baik pelanggan maupun pengembang menyukai paradigma prototype. Para
pemakai merasa enak dengan system aktual, sedangkan pengembang bisa
membangunnya dengan segera. Tetapi prototyping bisa juga menjadi masalah karena alasan-alasan sebagai berikut:
a) Pelanggan melihat apa yang tampak
sebagai versi perangkat lunak yang bekerja tanpa melihat bahwa prototype itu
dijalin bersama-sama “dengan permen karet dan baling wire”, tanpa melihat bahwa di dalam permintaan untuk
membuatnya bekerja, kita belum mencantumkan kualitas perangkat lunak secara
keseluruhan atau kemampuan pemeliharaan untuk jangka waktu yang panjang. Ketika
diberi informasi bahwa produk harus dibangun lagi agar tingkat kualitas yang tinggi
bisa dijaga, pelanggan akan meneriakkan kecurangan dan permintaan agar dipakai
“beberapa campuran” untuk membuat protipe menjadi sebuah produk yang bekerja
yang lebih sering terjadi, sehingga manajemen pengembangan perangkat lunak
menjadi penuh dengan belas kasihan.
b) Pengembang sering membuat
kompromi-kompromi implementasi untuk membuat prototype bekerja dengan cepat.
Sistem operasi atau bahasa pemrograman yang tidak sesuai bisa dipakai secara
sederhana karena mungkin diperoleh dan dikenal; algoritma yang tidak efisien
secara sederhana bisa diimplementasikan untuk mendemontrasikan kemampuan.
Setelah selang waktu tertentu, pengembang mungkin mengenali pilihan-pilihan
tersebut dan melupakan semua alasan mengapa mereka tidak cocok. Pilihan yang
kurang ideal telah menjadi bagian integral dari sebuah system.
Meskipun
berbagai masalah bisa terjadi, prototype bisa menjadi paradigm yang efektif
bagi rekayasa perangkat lunak. Kuncinya adalah mmendefinisikan aturan-aturan
main pada saat awal; yaitu pelanggan dan pengembang keduanya harus setuju bahwa
prototype dibangun untuk berfungsi sebagai mekanisme pendefinisian kebutuhan.
Prototipe kemudian disingkirkan (paling tidak sebagian), dan perangkat lunak
actual direkayasa dengan tertuju kepada kualitas dan kemampuan pemeliharaan.
4)
Pengembangan Evolusioner
Pengembangan evolusioner berdasarkan ide untuk
mengembangkan implementasi awal, memperlihatkannya kepada user untuk
dikomentari, dan memperbaikinya versi demi versi sampai sistem yang memenuhi
persyaratan diperoleh. Model pengembangan evolusioner dapat dilihat pada Gambar
1.5.
Gambar 1.5
Model Evolusioner
5)
Pengembangan Sistem Formal
Pengembangan sistem formal merupakan pendekatan
terhadap pengembangan perangkat lunak yang memiliki kesamaan dengan model air
terjun (waterfall). Tetapi proses
pengembangannya didasarkan pada transformasi matematis dari spesifikasi sistem
menjadi program yang dapat dijalankan. Model pengembangan sistem formal dapat
dilihat pada Gambar 1.6.
Gambar 1.6
Model Sistem Formal
6)
Pengembangan Berorientasi Pemakaian
Ulang
Pada pengembangan perangkat lunak yang besar,
terjadi pemakaian ulang. Hal ini biasanya terjadi secara informal ketika orang
yang bekerja di proyek tersebut mengetahui adanya rancangan atau kode yang
mirip dengan yang dibutuhkan. Mereka mencari rancangan atau kode ini,
memodifikasinya sebagaimana dibutuhkan, dan menggabungkannya dalam sistem.
Model pengembangan berorientasi pemakaian ulang dapat dilihat pada Gambar 1.7.
Gambar 1.7
Model Pengembangan Berorientasi Pemakaian Ulang
1.2 KEGUNAAN RPL
Perangkat lunak kini sudah menjadi kekuatan
yang menentukan.
Perangkat lunak menjadi mesin yang mengendalikan pengambilan keputusan di dalam
dunia bisnis. Berfungsi sebagai dasar dari semua bentuk pelayanan serta
penelitian keilmuan modern. Perangkat lunak dilekatkan pada semua sistem,
seperti transportasi, medis, telekomunikasi, militer, proses industri, hiburan,
produk kantor dan sebagainya. Program-program perangkat lunak sudah tersebar
secara luas, dan masyarakat memandangnya sebagai kenyataan teknologi dalam
kehidupan.
1.3 PERKEMBANGAN RPL
Selama masa awal era komputer, perangkat lunak dilihat
hanya sebagai suatu permenungan. Pemrograman komputer menjadi seni di mana di
situ terdapat banyak metode yang sistematis. Perkembangan perangkat lunak
sebenarnya tidak dapat diatur sampai terjadi jadwal yang bergeser, atau biaya
yang mulai melonjak. Para pemrogram kemudian mulai berusaha untuk membuat
semuanya benar kembali.
Era kedua evolusi sistem komputer melingkupi decade pertengahan
tahun 1960 dan 1970-an. Sistem multiprogram dan multiprosesor memperkenalkan
konsep baru interkasi manusia dan komputer. Konsep ini membuka sebuah dunia
aplikasi yang baru serta tingkat kecanggihan perangkat lunak dan perangkat
keras yang baru pula. Sistem real-time dapat mengumpulkan, menganalisis, serta
mengubah data dari banyak sumber sehingga proses pengontrolan dan penghasilan
output tidak lagi berada dalam skala menit, melainkan detik. Kemajuan dalam
penyimpanan online membawa ke generasi pertama sistem manajemen database.
Tabel 1.1 perkembangan RPL
Tahun-Tahun
Awal
|
Era
Kedua
|
Era
Ketiga
|
Era
Keempat
|
- Orientasi Batch
- Distribusi terbatas
- Perangkat lunak customisasi
|
- Multiuser
- Real-time
- Database
- Perangkat lunak produk
|
- Sistem terdistribusi
- Embedded intelligence
- Perangkat keras rendah biaya
|
- System desktop bertenaga kuat
- Teknologi berorientasi objek
- Sistem pakar
- Jarigan syaraf tiruan
- Komputasi parallel
- Komputer jaringan
|
1.4 DESKRIPSI RPL
Secara umum rekayasa perangkat lunak memakai
pendekatan yang sistematis dan terorganisir terhadap pekerjaan karena cara ini
seringkali paling efektif untuk menghasilkan perangkat lunak. Rekayasa perangkat lunak adalah disiplin ilmu yang membahas semua aspek
produksi perangkat lunak. Mulai dari tahap awal spesifikasi sistem sampai
pemeliharaan sistem setelah digunakan. Pada definisi ini ada dua istilah
kunci:
1)
Disiplin Rekayasa
Perekayasa membuat suatu alat bekerja. Mereka
menerapkan teori, metode, dan alat bantu yang sesuai. Selain itu mereka juga
menggunakannya dengan selektif dan selalu mencoba mencari solusi terhadap
permasalahan, walaupun tidak ada teori atau metode yang mendukung. Perekayasa
juga menyadari bahwa mereka harus bekerja dalam batasan organisasi dan
keuangan, sehingga mereka berusaha mencari solusi dalam batasan-batasan ini.
2)
Semua Aspek Produksi Perangkat Lunak
Rekayasa perangkat lunak tidak hanya berhubungan
dengan proses teknis dari pengembanga perangkat lunak, tetapi juga dengan
kegiatan seperti manajemen proyek perangkat lunak dan pengembangan alat bantu,
metode, dan teori untuk mendukung produksi perangkat lunak.
1. 5 KARAKTERISTIK RPL
Perangkat lunak lebih kepada
logika dan bukan semata elemen fisik. Perbedaan perangkat lunak dengan perangkat keras
yang mendasar adalah:
1)
Perangkat
lunak dibangun dan dikembangkan, tidak dibuat dalam bentuknya yang klasik.
2)
Perangkat
lunak tidak pernah usang.
Sebagian
besar perangkat lunak dibuat secara custom (pemesanan) serta tidak dapat
dirakit dari komponen yang sudah ada.
1.6 KOMPONEN RPL
Bersamaan dengan perkembangan disiplin keteknikan
diciptakan sekumpulan komponen perancangan standar. Komponen-komponen yang dapat digunakan lagi sudah diciptakan sehingga
ahli teknik dapat benar-benar berkonsentrasi pada elemen-elemen inovatif suatu
perancangan. Dalam dunia perangkat keras hal ini merupakan hal yang harus
dicapai dalam skala yang luas.
Reusability meruapakan suatu cirri penting dari komponen perangkat lunak
kualitas tinggi. Sebuah komponen perangkat lunak harus didesain dan
diimplementasi sehingga dapat dipakai lagi pada berbagai program yang berbeda.
Komponen perangkat lunak dibangun dengan bahasa pemrograman yang memiliki
kosakata terbatas, sebuah tata bahasa yang dibatasi secara eksplisit. Bahasa tingkat mesin merupakan
perwakilan simbolik dari serangkaian instruksi CPU. Bahasa tingkat menengah memungkinkan pengembang perangkat lunak
serta program tidak bergantung pada mesin.
1. 7 APLIKASI RPL
Perangkat lunak dapat diaplikasikan ke berbagai
situasi dimana serangkaian procedural (seperti algoritma) telah didefinisikan
(pengecualian-pengecualian yang dapat dicatatat pada aturan ini adalah sistem
pakar dan jaringan syaraf tiruan dalam aplikasi kecerdasan buatan). Kandundan informasi dan determinasi merupakan faktor penting dalam
menentukan sifat aplikasi perangkat lunak.
1.8 EVALUASI
1) Apakah yang dimaksud dengan
perangkat lunak?
2) Apakah rekayasa perangkat
lunak itu?
3) Apa perbedaan antara rekayasa
perangkat lunak dan computer science?
4) Apa perbedaan rekayasa
perangkat lunak dan rekayasa sistem?
5) Apakah yang dimaksud dengan
proses perangkat lunak?
6) Apakah model proses perangkat
lunak itu?
