Analisis Perancangan Perangkat Lunak

MATERI 1
PENGANTAR
REKAYASA
PERANGKAT LUNAK
Direkonstruksi Oleh :
Muhammad Adri, S.Pd., M.T
Email : mhd.adri@unp.ac.id

Lisensi Dokumen:
Copyright © 2020 Universitas Negeri Padang
Seluruh dokumen di e-Learning Universitas Negeri Padang, hanya digunakan untuk kalangan
Internal Universitas, untuk kebutuhan Perkuliahan Online. Penggunaan dokumen ini di luar UNP tidak
diizinkan dan tidak diperbolehkan melakukan penulisan ulang, kecuali mendapatkan ijin terlebih dahulu
dari Penulis dan Universitas Negeri Padang.

Kita hidup dalam masyarakat informasi di mana kebanyakan orang terlibat dalam
kegiatan yang terhubung baik dengan memproduksi atau mengumpulkan data, atau
mengatur, memproses dan menyimpan data, dan mengambil dan menyebarkan
informasi yang tersimpan, atau menggunakan informasi tersebut untuk pengambilan
keputusan. Perkembangan luar biasa telah terjadi dalam teknologi perangkat keras
komputer, tetapi kunci untuk membuat teknologi ini bermanfaat bagi manusia
berbohong dengan teknologi perangkat lunak.
Dalam beberapa tahun terakhir industri perangkat lunak menunjukkan yang
tertinggi tingkat pertumbuhan di seluruh dunia, India tidak terkecuali. Buku ini tentang
rekayasa perangkat lunak dikhususkan untuk presentasi konsep, alat dan teknik
digunakan selama berbagai fase pengembangan perangkat lunak. Untuk menyiapkan
pengaturan untuk subjek, dalam bab pengantar ini, kami memberikan tinjauan historis
tentang subjek rekayasa perangkat lunak.

MODUL 1 APPL – 1| TEKNIK INFORMATIKA

Materi 1. Pengantar Rekayasa Perangkat Lunak

A. SEJARAH REKAYASA PERANGKAT LUNAK

Rekayasa Perangkat Lunak hari ini bukanlah suatu bahasan yang muncul
belakangan dalam kajian Ilmu Komputer, namun kajian ini ikut berkembanng sejalan
dengan perkembangan perangkat keras komputer. Hal ini dapat kita lihat pada sejarah
perjalanan panjang dunia perangkat lunak.

1. Istilah 'Rekayasa Perangkat Lunak

Saat mendokumentasikan sejarah rekayasa perangkat lunak, kita harus

mulai dengan komputer IBM 360 sistem pada tahun 1964 yang menggabungkan,
untuk pertama kalinya, fitur aplikasi ilmiah dan bisnis. Sistem komputer ini
mendorong orang untuk mencoba mengembangkan perangkat lunak untuk fisik
yang besar dan kompleks dan sistem manajemen, yang selalu menghasilkan
sistem perangkat lunak besar. Perlunya disiplin pendekatan untuk
pengembangan perangkat lunak terasa kuat ketika waktu dan biaya
membengkak, kualitas yang bertahan lama masalah, dan biaya perawatan yang
tinggi, dll., naik sangat tinggi, sehingga memunculkan apa yang saat itu luas
disebut sebagai "Krisis Perangkat Lunak." Dalam sebuah surat kepada Dr. Richard
Thayer, editor pertama IEEE Computer Society Publication on Rekayasa
Perangkat Lunak, Bauer (2003) yang dikreditkan telah menciptakan istilah
"Rekayasa Perangkat Lunak", menceritakan pengalamannya tentang asal-usul
rekayasa perangkat lunak. Di Komite Sains NATO Dr. II Rabi, peraih Nobel dan
fisikawan terkenal memberi curhat untuk krisis ini dan fakta bahwa kemajuan
dalam perangkat lunak tidak sesuai dengan kemajuan dalam perangkat keras.
Komite membentuk Kelompok Studi Ilmu Komputer pada tahun 1967 dengan
anggota diambil dari sejumlah negara menilai seluruh bidang ilmu komputer.

Dalam anggota pertemuan pertamaRekayasa Perangkat Lunak

membahas berbagai proyek ilmiah yang menjanjikan tetapi mereka jauh dari
tema pemersatu yang sama diinginkan oleh Kelompok Studi. Dalam suasana
kemarahan yang tiba-tiba, Profesor (Dr.) Fritz Bauer dari Munich, the anggota dari
Jerman Barat, mengatakan, “Seluruh masalah datang dari kenyataan bahwa ada
begitu banyak mengutak-atik perangkat lunak. Itu tidak dibuat dalam proses
fabrikasi yang bersih. Yang kita butuhkan adalah perangkat lunak

2|Analisis Perancangan Peangkat Lunak

 Materi 1. Pengantar Rakayasa Perangkat Lunak|

teknik." Pernyataan itu mengejutkan, tetapi tersangkut di benak para anggota

kelompok (Bauer 2003). Atas rekomendasi Grup, Konferensi Kerja Rekayasa
Perangkat Lunak dilaksanakan diadakan di Garmish, Jerman Barat, selama 7-10
Oktober 1968 dengan Bauer sebagai Ketua untuk membahas berbagai hal
masalah dan masalah seputar pengembangan sistem perangkat lunak besar. Di
antara 50 atau lebih peserta adalah P. Naur, JN Buxton, dan Dijkstra, yang
masing-masing memberikan kontribusi signifikan pertumbuhan rekayasa
perangkat lunak di tahun-tahun berikutnya.

Laporan pada Konferensi ini diterbitkan setahun kemudian (Naur dan

Randell, 1969) dikreditkan ke Bauer telah menciptakan istilah "Rekayasa
Perangkat Lunak." Komite Ilmu Pengetahuan NATO mengadakan konferensi
keduanya di Roma, Italia pada tahun 1969 dan menamakannya "Konferensi
Rekayasa Perangkat Lunak." Konferensi Internasional pertama tentang Rekayasa
Perangkat Lunak diadakan pada tahun 1973. Institute of Insinyur Elektronik dan
Listrik (IEEE) memulai jurnalnya "Transaksi IEEE pada Perangkat Lunak
Teknik”pada tahun 1975. Pada tahun 1976, IEEE Transaksi di Komputer
merayakan nya 25 th ulang tahun.

Untuk masalah khusus itu, Boehm menyumbangkan makalahnya yang

sekarang terkenal yang berjudul, Rekayasa Perangkat Lunak (Boehm 1976), yang
dengan jelas mendefinisikan ruang lingkup rekayasa perangkat lunak. Pada
tahun 1975, Brooks (1975), yang mengarahkan pengembangan perangkat lunak
sistem operasi IBM 360 selama sepuluh tahun yang melibatkan lebih dari 100
orang-bulan menulis bukunya yang membuat zaman, "The Mythical Man-Month
”di mana ia mengeluarkan banyak masalah yang terkait dengan perkembangan
besar program perangkat lunak dalam lingkungan multi-orang. Pada 1981,
Boehm (1981) mengeluarkan bukunya yang luar biasa berjudul “Rekayasa
Perangkat Lunak Ekonomi ”di mana banyak masalah manajerial termasuk
perkiraan waktu dan biaya pengembangan perangkat lunak disorot. Rekayasa
perangkat lunak yang lambat dan mantap tumbuh menjadi disiplin yang tidak
hanya direkomendasikan solusi teknis tetapi juga manajerial untuk berbagai
masalah pengembangan perangkat lunak.

Analisis Perancanan Perangkat Lunak |3

Materi 1. Pengantar Rekayasa Perangkat Lunak

2. Perkembangan Alat dan Teknik Rekayasa Perangkat Lunak

Tujuh puluhan melihat pengembangan berbagai konsep teknik, alat, dan

teknik yang memberikan dasar bagi pertumbuhan lapangan. Royce (1970)
memperkenalkan fase siklus hidup pengembangan perangkat lunak. Wirth (1971)
menyarankan perbaikan bertahap sebagai metode program
pengembangan. Hoare et al. (1972) memberikan konsep pemrograman
terstruktur dan menekankan kebutuhan untuk menghilangkan pernyataan
GOTO. Parnas (1972) menyoroti keutamaan modul dan memberi spesifikasinya.
Endres (1975) membuat analisis kesalahan dan penyebabnya dalam program
komputer. Fagan (1976) meneruskan metode formal inspeksi kode untuk
mengurangi kesalahan pemrograman. McCabe (1976) dikembangkan
representasi grafik aliran program komputer dan ukuran kerumitannya yang
membantu dalam pengujian. Halstead (1977) memperkenalkan istilah baru "Ilmu
Perangkat Lunak" di mana ia memberikan ide-ide baru untuk digunakan informasi
tentang jumlah operator dan operan unik dalam suatu program untuk
memperkirakan ukuran dan kerumitannya.

Gilb (1977) menulis buku pertama tentang metrik perangkat lunak. Jones
(1978) menyoroti kesalahpahaman seputar kualitas dan produktivitas perangkat
lunak dan menyarankan berbagai ukuran kualitas dan produktivitas. DeMarco
(1978) memperkenalkan konsep diagram aliran data untuk analisis
terstruktur. Constantine dan Yourdon (1979) memberikan prinsip-prinsip desain
terstruktur.Eighties melihat konsolidasi ide-ide tentang rekayasa perangkat
lunak. Boehm (1981) disajikan model COCOMO untuk estimasi perangkat
lunak. Albrecht dan Gaffney (1983) memformalkan konsep "titik fungsi" sebagai
ukuran ukuran perangkat lunak. Gagasan berkembang selama dekade ini di
berbagai bidang seperti model proses, alat untuk analisis, desain dan pengujian.

Konsep baru muncul di bidang pengukuran, keandalan, estimasi,

usabilitas dan manajemen proyek. Dekade ini menyaksikan juga penerbitan buku
penting berjudul, “Mengelola Perangkat Lunak Proses ”oleh Humprey
(1989), di mana fondasi model kematangan kemampuan diletakkan. Sembilan
puluhan melihat sejumlah besar kegiatan di bidang kualitas perangkat lunak,
khususnya, di bidang sistem kualitas. Paulk et al. (1993) dan Paulk (1995)

4|Analisis Perancangan Peangkat Lunak

 Materi 1. Pengantar Rakayasa Perangkat Lunak|

mengembangkan model kematangan kemampuan. Gamma et al. (1995)

memberikan konsep "pola desain." Dekade ini juga melihat publikasi yang bagus
buku teks tentang rekayasa perangkat lunak (Pressman 1992, Sommerville
1996). Dekade ini juga telah melihat pengenalan banyak ide baru seperti
arsitektur perangkat lunak (Shaw dan Garlan, 1996) dan komponen- rekayasa
perangkat lunak berbasis (Pree 1997).

Perkembangan lain dalam dekade ini adalah berorientasi objek analisis

dan desain dan bahasa pemodelan terpadu (Rumbaugh et al. 1998 dan Booch et
al. 1999). Tahun-tahun awal abad kedua puluh satu telah melihat konsolidasi
bidang desain pola, arsitektur perangkat lunak, dan rekayasa perangkat lunak
berbasis komponen. Kami telah menyatakan di atas bahwa banyak masalah yang
dihadapi dalam mengembangkan sistem perangkat lunak besar dimasukkan ke
dalam krisis perangkat lunak jangka dan alasan utama untuk mendirikan disiplin
rekayasa perangkat lunak adalah untuk meredakan krisis perangkat lunak. Di
bagian selanjutnya kita akan melihat lebih jelas faktor-faktor yang merupakan
krisis perangkat lunak.

B. KRISIS PERANGKAT LUNAK

Selama akhir 1960-an dan 1970-an, ada protes atas "krisis perangkat lunak"
yang akan datang. Itu gejala krisis seperti itu muncul kemudian dan hadir bahkan hari
ini. Gejala-gejalanya adalah sebagai berikut:Biaya perangkat lunak telah menunjukkan
tren meningkat, melampaui biaya perangkat keras. Boehm (1976, 1981) menunjukkan
bahwa sejak tahun lima puluhan, persentase dari total biaya perhitungan disebabkan
untuk perangkat keras telah berkurang secara dramatis dan yang disebabkan oleh
perangkat lunak telah sesuai meningkat (Gbr. 1.1). Sedangkan biaya perangkat lunak
hanya sedikit di atas 20% pada 1950-an, itu hampir 60% pada 1970-an, dan sekitar 80%
pada 1980-an.
1. Hari ini, sistem komputer yang kita miliki beli sebagai 'perangkat keras' umumnya
membuat vendor mengeluarkan biaya sekitar tiga kali lipat untuk perangkat
lunak seperti halnya untuk perangkat keras (Pressman 1992).

Analisis Perancanan Perangkat Lunak |5

Materi 1. Pengantar Rekayasa Perangkat Lunak

Gambar 1.1. Biaya perangkat keras dan perangkat lunak Rekayasa Perangkat Lunak
2. Biaya pemeliharaan perangkat lunak telah meningkat dan telah melampaui
biaya pengembangan. Boehm (1981) telah menunjukkan bahwa sebagian besar
biaya perangkat lunak adalah karena pemeliharaan daripada pengembangan .
3. Perangkat lunak hampir selalu dikirim terlambat dan melebihi biaya yang
dianggarkan, menunjukkan waktu dan pembengkakan biaya.
4. Tidak memiliki transparansi dan sulit untuk dipertahankan.
5. Kualitas perangkat lunak seringkali kurang memadai.
6. Ini sering tidak memuaskan pelanggan.
7. Produktivitas orang-orang perangkat lunak tidak mengikuti permintaan layanan
mereka.
8. Kemajuan dalam pengembangan perangkat lunak sulit diukur.
9. Sangat sedikit data dunia nyata yang tersedia pada proses pengembangan
perangkat lunak. Karena itu belum dimungkinkan untuk menetapkan standar
realistis.
10. Bagaimana orang-orang bekerja selama pengembangan perangkat lunak belum
dipahami dengan benar. Salah satu karya paling awal yang menjelaskan
sebagian besar penyebab krisis perangkat lunak adalah oleh Brooks (1972). Kita
akan melihat sekilas karya Brooks di bagian selanjutnya.

6|Analisis Perancangan Peangkat Lunak

 Materi 1. Pengantar Rakayasa Perangkat Lunak|

C. EVOLUSI PRODUK SISTEM PEMROGRAMAN

Buku 'The Mythical Man-Month' karya Brooks (1975) menceritakan

pengalamannya tentang perkembangan dari perangkat lunak sistem operasi IBM 360. Di
antara banyak pengamatannya yang signifikan, salah satunya relevan pada tahap ini
adalah pengamatannya tentang pengaruh beberapa pengguna dan banyak pengembang
pada waktu pengembangan perangkat lunak. Ia membedakan program yang ditulis oleh
seseorang untuk penggunaannya dari a produk pemrograman, sistem pemrograman,
dan dari produk sistem pemrograman. Suatu program selesai dengan sendirinya,
dijalankan oleh penulis sendiri (sendiri), dan dijalankan pada mesin di mana itu
dikembangkan. Sebuah produk pemrograman adalah program yang ditulis secara umum
sedemikian rupa sehingga dapat dijalankan, diuji, diperbaiki, dan diperluas oleh siapa
saja. Ini berarti bahwa program tersebut harus diuji, rentang dan bentuk input
dieksplorasi, dan ini direkam dengan baik melalui dokumentasi.
Sebuah program,ketika dikonversi menjadi produk pemrograman, biaya, sebagai
aturan praktis, tiga kali lipat dari itu sendiri. Sistem pemrograman adalah kumpulan
program yang saling berinteraksi, terkoordinasi dalam fungsi dan disiplin dalam format,
sehingga kumpulan merupakan seluruh fasilitas untuk tugas-tugas besar. Di sebuah
komponen sistem pemrograman, input dan output harus sesuai dengan sintaks dan
semantik dengan tepat antarmuka yang ditentukan, gunakan anggaran sumber daya
yang ditentukan — ruang memori, perangkat input-output, dan waktu komputer, dan
harus diuji dengan komponen lain di semua kombinasi yang diharapkan. Secara umum
biaya setidaknya tiga kali lipat dari program yang berdiri sendiri dari fungsi yang sama.
Sebuah produk sistem pemrograman memiliki semua fitur dari produk pemrograman
dan dari sistem pemrograman. Biasanya biaya setidaknya sembilan kali lipat dari
program yang berdiri sendiri fungsi yang sama.
Ini menunjukkan bagaimana biaya produk naik sebagai suatu program yang
secara perlahan dikonversi menjadi produk sistem pemrograman. Diskusi ini oleh Brooks
dimaksudkan untuk membawa pulang pokok bahasan mengembangkan perangkat lunak
yang berisi serangkaian program yang saling berinteraksi penggunaan oleh orang selain
pengembang membutuhkan lebih banyak waktu dan upaya daripada yang dibutuhkan
untuk mengembangkan program untuk digunakan oleh pengembang. Karena sebagian
besar perangkat lunak saat ini digunakan oleh orang selain dari pengembang, biaya

Analisis Perancanan Perangkat Lunak |7

Materi 1. Pengantar Rekayasa Perangkat Lunak

pengembangan perangkat lunak pasti akan menjadi penghalang. Perangkat lunak

metode rekayasa, alat, dan prosedur membantu dalam merampingkan kegiatan
pengembangan sehingga perangkat lunak dikembangkan dengan kualitas dan
produktivitas tinggi dan dengan biaya rendah.

Gambar 1.2. Tingkat pemrograman

Beberapa alasan utama untuk efek berlipat ganda dari beberapa pengguna dan
pengembang ini waktu pengembangan perangkat lunak dan, secara umum, asal-usul
krisis perangkat lunak dapat lebih dihargai jika kita memahami karakteristik perangkat
lunak dan cara mereka berbeda dari yang ada di lingkungan manufaktur.

D. KARAKTERISTIK PERANGKAT LUNAK

Perangkat lunak lebih logis daripada elemen sistem fisik. Oleh karena itu,
perangkat lunak memiliki karakteristik yang sangat berbeda dari perangkat keras
(Wolverton 1974, dan Pressman 1992). Beberapa dari perbedaan utama adalah sebagai
berikut:

1) Perangkat lunak dikembangkan atau direkayasa, tidak diproduksi.

a. Konsep 'bahan baku' tidak ada di sini. Lebih baik divisualisasikan sebagai suatu
proses, daripada produk (Jensen dan Tonies, 1979).
b. 'Elemen manusia' sangat tinggi dalam pengembangan perangkat lunak,
dibandingkan dengan pabrikan turing.

8|Analisis Perancangan Peangkat Lunak

 Materi 1. Pengantar Rakayasa Perangkat Lunak|

c. Produktivitas pengembangan sangat tidak pasti, bahkan dengan produk

standar, bervariasi sangat dengan keterampilan para pengembang.
d. Alat pengembangan, teknik, standar, dan prosedur sangat bervariasi di dan
dalam suatu organisasi.
e. Masalah kualitas dalam pengembangan perangkat lunak sangat berbeda
dengan yang ada di manufakturing. Sedangkan karakteristik kualitas
manufaktur dapat ditentukan secara objektif dan mudah diukur, mereka yang
berada di lingkungan rekayasa perangkat lunak agak sulit dipahami.

2) Pengembangan perangkat lunak menghadirkan lingkungan kerja.

a. Di sini setiap produk dibuat khusus dan karenanya unik.
b. Tidak dapat dirakit dari komponen yang ada.
c. Semua kerumitan bengkel kerja ( yaitu , masalah desain, estimasi, dan jadwal-
ing) hadir di sini.
d. Keterampilan manusia, elemen paling penting dalam sebuah job shop, juga
elemen yang paling penting ment dalam pengembangan perangkat lunak.

3) Waktu dan upaya untuk pengembangan perangkat lunak sulit diperkirakan.

a. Pekerjaan yang menarik dilakukan dengan mengorbankan pekerjaan yang
membosankan, dan dokumentasi, menjadi membosankan bekerja, mendapat
prioritas paling sedikit.
b. Melakukan pekerjaan dengan cara yang cerdas cenderung menjadi
pertimbangan yang lebih penting daripada mendapatkannya dilakukan secara
memadai, tepat waktu, dan dengan biaya yang masuk akal.
c. Pemrogram cenderung optimis, tidak realistis, dan perkiraan waktu mereka
untuk tugas kebanyakan mencerminkan kecenderungan ini.
d. Pemrogram kesulitan berkomunikasi.

4) Persyaratan pengguna seringkali tidak dipahami dengan baik; Oleh karena itu
sepotong perangkat lunak mengalami banyak modifikasi sebelum diterapkan
dengan memuaskan.
5) Hampir tidak ada standar objektif atau langkah-langkah yang digunakan untuk
mengevaluasi kemajuan pengembangan perangkat lunak.
Analisis Perancanan Perangkat Lunak |9
Materi 1. Pengantar Rekayasa Perangkat Lunak

6) Menguji perangkat lunak sangat sulit, karena bahkan program berukuran sedang
(<5.000 pernyataan yang dapat dieksekusi) dapat berisi jalur yang cukup dapat
dieksekusi ( mis ., cara untuk mendapatkan dari mulai dari program hingga akhir)
sehingga proses pengujian setiap path melalui Program bisa sangat mahal.
7) Perangkat lunak tidak aus.
a. Perangkat lunak biasanya tidak kehilangan fungsinya saat digunakan.
b. Akan tetapi, fungsionalitasnya akan berkurang tepat waktu, karena persyaratan
pengguna berubah.
c. Ketika cacat ditemukan, mereka dihapus dengan menulis ulang kode yang
relevan, bukan oleh menggantinya dengan kode yang tersedia. Itu artinya
konsep mengganti yang rusak kode dengan kode cadangan sangat tidak biasa
dalam pengembangan perangkat lunak.
d. Ketika cacat dihapus, ada kemungkinan bahwa cacat baru diperkenalkan.

8) Hardware memiliki model fisik untuk digunakan dalam mengevaluasi keputusan

desain. Desain perangkat lunak evaluasi, di sisi lain, bertumpu pada penilaian dan
intuisi.
9) Perangkat keras, karena keterbatasan fisiknya, memiliki batasan praktis karena
kompleksitas setiap desain perangkat keras harus diwujudkan sebagai
implementasi fisik. Perangkat lunak, pada sisi lain, bisa sangat kompleks sambil
tetap memenuhi hampir semua kebutuhan.
10) Ada perbedaan besar antara manajemen proyek perangkat keras dan perangkat
lunak. Kontrol tradisional untuk proyek perangkat keras mungkin kontraproduktif
dalam proyek perangkat lunak. Misalnya, melaporkan persen yang diselesaikan
dalam hal Lines of Code dapat sangat menyesatkan.Sekarang saatnya untuk
memberikan beberapa definisi. Bagian selanjutnya melakukan ini.

E. DEFINISI

1. Perangkat lunak

Menurut Webster's New Intercollegiate Dictionary, 1979, “Perangkat lunak

adalah seluruh rangkaian program, prosedur, dan dokumentasi terkait yang
terkait dengan a sistem dan terutama sistem komputer. "The New Webster's

10 | A n a l i s i s P e r a n c a n g a n P e a n g k a t L u n a k
 Materi 1. Pengantar Rakayasa Perangkat Lunak|

Dictionary, 1981, menyusun ulang definisi tersebut, mengarahkannya

sepenuhnya ke komputer: “Perangkat lunak adalah program dan dukungan
pemrograman yang diperlukan untuk menempatkan komputer melalui
komputernya tugas yang ditugaskan, yang dibedakan dari mesin yang
sebenarnya. " Definisi yang lebih ketat tetapi fungsional diberikan oleh Blum
(1992): “Perangkat lunak adalah instruksi terperinci yang mengontrol operasi
sistem komputer. Fungsinya adalah untuk :

a. mengelola sumber daya komputer organisasi

b. menyediakan alat untuk manusia untuk mengambil keuntungan dari
sumber daya ini,
c. bertindak sebagai perantara antara organisasi dan informasi yang
tersimpan.
Gilb (1977) mendefinisikan dua komponen utama perangkat lunak:

1) Logicware , urutan logis dari instruksi aktif yang mengendalikan urutan

eksekusi (urutan pemrosesan data) dilakukan oleh perangkat keras, dan

2) Dataware , bentuk fisik di mana semua informasi (pasif), termasuk

logicware, muncul ke perangkat keras, dan yang diproses sebagai hasil
dari logika perangkat logika.

Gambar 1.3 (Gilb 1977) menunjukkan tidak hanya dua elemen dari sistem
perangkat lunak, tetapi juga menunjukkan komponen lain juga.

Ada delapan level perangkat lunak yang memisahkan pengguna dari

perangkat keras. Mengikuti Gilb (1977) dan Blum (1992), kami menunjukkan
level-level ini pada Gambar 1.4.

A. Logika Perangkat Keras 1. Mesin Micrologic

B. Perangkat Lunak Sistem
C. Perangkat Lunak Aplikasi
2. Supervisor atau Eksekutif
3. Sistem Operasi
4. Penerjemah Bahasa
5. Program Utilitas
6. Perangkat Lunak Pertanyaan, File, dan
Basis Data
7. Bahasa dan Program Programming dan

A n a l i s i s P e r a n c a n a n P e r a n g k a t L u n a k | 11
Materi 1. Pengantar Rekayasa Perangkat Lunak

Assembly

D. Perangkat Lunak Pengguna Akhir

8. Bahasa dan Program Pengguna Generasi
Keempat, seperti SPSS, dbase-IV, dan
Lotus 1-2-3, SQL, dll.

12 | A n a l i s i s P e r a n c a n g a n P e a n g k a t L u n a k
 Materi 1. Pengantar Rakayasa Perangkat Lunak|

Apa yang penting untuk dicatat di sini adalah, bertentangan dengan

kepercayaan populer, perangkat lunak tidak hanya mencakup
yang program tetapi juga prosedur dan dokumentasi terkait . Juga penting untuk
dicatat adalah bahwa perangkat lunak kata adalah kata benda kolektif seperti
halnya informasi kata ; jadi huruf s tidak boleh digunakan setelah itu. Sementara
mengacu pada sejumlah paket, seseorang harus menggunakan istilah paket
perangkat lunak . Demikian pula, salah satu harus menggunakan istilah produk
perangkat lunak , buah perangkat lunak , dan sebagainya, dan bukan
kata software .

2. Engineering

New Intercollegiate Webster's Dictionary, 1979, mendefinisikan

istilah engineering sebagai “Penerapan sains dan matematika dengan mana sifat-
sifat materi dan sumbernya energi di alam dibuat bermanfaat bagi manusia

A n a l i s i s P e r a n c a n a n P e r a n g k a t L u n a k | 13
Materi 1. Pengantar Rekayasa Perangkat Lunak

dalam struktur, mesin, produk, sistem dan proses”.Dengan demikian, teknik

menunjukkan penerapan pengetahuan ilmiah untuk pemecahan masalah praktis .

3. Rekayasa Perangkat Lunak

Naur (Naur dan Randell 1969) yang ikut mengedit laporan tentang
konferensi NATO yang terkenal di Garnish juga ikut menulis salah satu buku
paling awal tentang masalah ini (Naur et al. 1976). Di dalam buku, ide-ide di
balik rekayasa perangkat lunak diberikan sebagai berikut:

a. Mengembangkan produk perangkat lunak besar jauh lebih kompleks

daripada mengembangkan program yang berdiri sendiri
b. Prinsip-prinsip desain teknik harus diterapkan pada tugas pengembangan
perangkat lunak besar. produk barang.

Ada banyak definisi "Rekayasa Perangkat Lunak" seperti halnya ada penulis. Kami
berusaha sekilas melalui sampel definisi yang diberikan oleh eksponen di
lapangan. Bauer (1972) memberikan definisi paling awal untuk rekayasa
perangkat lunak (Bauer 1972, p. 530): "... pembentukan dan penggunaan prinsip-
prinsip teknik suara (metode) untuk mendapatkan perangkat lunak ekonomis
yang andal dan bekerja pada mesin nyata. " Menurut Boehm (1976), rekayasa
perangkat lunak adalah “... aplikasi praktis dari pengetahuan ilmiah dalam desain
dan konstruksi komputer program dan dokumentasi terkait yang diperlukan
untuk mengembangkan, mengoperasikan, dan memeliharanya. " Boehm (1976)
memperluas idenya dengan menekankan bahwa pengembangan perangkat lunak
paling mendesak masalah adalah di bidang analisis persyaratan, desain,
pengujian, dan pemeliharaan perangkat lunak aplikasi oleh teknisi dalam konteks
yang didorong oleh ekonomi daripada di bidang desain rinci dan pengkodean
perangkat lunak sistem oleh para ahli dalam konteks
yang relatif independen terhadap ekonomi .

DeRemer dan Kron (1976) mengakui rekayasa perangkat lunak untuk

menangani pemrograman-in-the-besar , sementara Parnas (1978) berpandangan

14 | A n a l i s i s P e r a n c a n g a n P e a n g k a t L u n a k
 Materi 1. Pengantar Rakayasa Perangkat Lunak|

bahwa rekayasa perangkat lunak berkaitan dengan konstruksi multi-orang

perangkat lunak multi-versi . ' Sommerville (1992) merangkum faktor-faktor
umum yang melibatkan rekayasa perangkat lunak:

a. Sistem perangkat lunak dibangun oleh tim daripada individu.

b. Menggunakan prinsip-prinsip teknik dalam pengembangan sistem ini yang
mencakup teknis dan aspek non-teknis.

Definisi yang lebih baru oleh Wang dan King (2000) menganggap rekayasa
perangkat lunak sebagai suatu disiplin dan membuat prinsip-prinsip teknik dan
atribut produk lebih eksplisit: “Rekayasa perangkat lunak adalah disiplin yang
mengadopsi pendekatan rekayasa seperti yang ditetapkan metodologi, proses,
alat, standar, metode organisasi, metode manajemen, kualitas sistem jaminan,
dan sejenisnya untuk mengembangkan perangkat lunak skala besar dengan
produktivitas tinggi, rendah biaya, kualitas yang dapat dikendalikan, dan jadwal
pengembangan pengukuran. "

4. Teknik Konvensional dan Rekayasa Perangkat Lunak: Persamaan dan

Perbedaan

Jelas dari beberapa definisi yang disebutkan di atas bahwa rekayasa

perangkat lunak berbagi cukup beberapa hal umum dengan prinsip-prinsip teknik
konvensional. Di sini kami menguraikan kesamaan-kesamaan ini dan beberapa
perbedaan antara kedua disiplin ilmu tersebut. Jensen dan Tonies (1979)
menganggap rekayasa perangkat lunak terkait dengan desain perangkat lunak
atau produk pengolah data dan termasuk dalam domain penyelesaian
masalahnya , yang mencakup kelas masalah yang terkait dengan perangkat
lunak dan pemrosesan data. Mereka memperluas ide mereka dengan
menggambar analogi dari metode yang umumnya digunakan dalam
rekayasa. Menurut mereka, sama seperti yang dirayakan ilmiah metode yang
digunakan dalam bidang penelitian ilmiah, langkah - langkah proses desain
teknik digunakan dalam proses pemecahan masalah di bidang teknik. Langkah-
langkah ini, yang sebagian besar berulang, adalah:
A n a l i s i s P e r a n c a n a n P e r a n g k a t L u n a k | 15
Materi 1. Pengantar Rekayasa Perangkat Lunak

a. Perumusan masalah,
b. Analisis masalah,
c. Mencari alternatif,
d. Keputusan,
e. Spesifikasi, dan
f. Implementasi.

Jenson dan Tonies menyarankan agar langkah-langkah ini berlaku untuk

bidang rekayasa perangkat lunak juga. Pressman (1992) menganggap rekayasa
perangkat lunak sebagai hasil dari perangkat keras dan sistem rekayasa, meliputi
satu set tiga elemen kunci — metode, alat, dan prosedur yang memungkinkan
manajer untuk mengontrol proses pengembangan perangkat lunak. Menurut
Pressman, metode menyediakan "cara untuk" teknis untuk membangun
perangkat lunak; alat menyediakan dukungan otomatis atau semi-otomatis
untuk metode; dan prosedur menentukan urutan penerapan metode, hasil,
kontrol, dan tonggak sejarah. Wang dan King (2000) telah menyoroti fondasi
filosofis dari rekayasa perangkat lunak. Dibandingkan dengan disiplin teknik
tradisional, rekayasa perangkat lunak menunjukkan beberapa yang luar biasa
perbedaan:

a. Dalam rekayasa konvensional, seseorang bergerak dari desain abstrak ke

produk beton. Di Sebaliknya, dalam rekayasa perangkat lunak, seseorang
bergerak dari desain ke pengkodean (yang dapat dipertimbangkan sebagai
abstrak).

Rekayasa Perangkat Lunak Desain Abstrak Lebih Banyak Kode

Abstrak
Abstrak Manufaktur Desain Abstrak Concrete Products

b. Domain masalah rekayasa perangkat lunak bisa hampir apa saja, dari proses
kata- untuk kontrol waktu nyata dan dari game ke robotika. Dibandingkan

16 | A n a l i s i s P e r a n c a n g a n P e a n g k a t L u n a k
 Materi 1. Pengantar Rakayasa Perangkat Lunak|

dengan teknik lainnya disiplin, karena itu jauh lebih luas cakupannya dan
dengan demikian menawarkan tantangan yang lebih besar.
c. Teknik manufaktur tradisional yang biasanya menekankan produksi massal
dimuat dengan fitur produksi. Dengan demikian, sangat intensif dalam
produksi . Rekayasa perangkat lunak, pada sisi lain, secara inheren desain
intensif .
d. Standardisasi produk membantu dalam pengurangan biaya dalam
pembuatan, sedangkan kemungkinan seperti itu jauh dalam rekayasa
perangkat lunak. Namun, kemungkinan standardisasi proses adalah sangat
tinggi pada yang terakhir.
e. Jumlah gagasan khusus domain dan aplikasi yang tidak terbatas berlaku di
bidang teknik disiplin ilmu. Rekayasa perangkat lunak, di sisi lain,
menggunakan angka yang terbatas, tetapi universal konsep, misalnya,
struktur logis standar urutan, kondisi, dan pengulangan.

F. ESENSI REKAYASA PERANGKAT LUNAK

Proyek perangkat lunak, tampak sederhana dan tanpa masalah, namun dapat
berubah menjadi proyek rawan kesalahan dengan overruns waktu dan biaya
tinggi. Menurut Brooks, esensi kesulitan yang terkait dengan rekayasa perangkat lunak
terletak pada spesifikasi, desain, dan pengujian konstruksi konseptual sementara
kesalahan selama representasi kecelakaan . Rekayasa perangkat lunak harus
membahas esensi, dan bukan kecelakaan . Sifat esensi dari sistem perangkat lunak
modern, menurut Brooks, Jr (1986) adalah berikut:
1. Kompleksitas:Tidak ada dua bagian dari produk perangkat lunak yang sama.
2. Kesesuaian:Tidak seperti hukum alam dalam sistem fisik, tampaknya tidak ada
menjadi teori pemersatu untuk sistem perangkat lunak.
3. Kemampuan berubah: Sementara produk yang diproduksi tidak terlalu sering
berubah, produk perangkat lunak berubah, terutama dengan persyaratan pengguna
berubah.

A n a l i s i s P e r a n c a n a n P e r a n g k a t L u n a k | 17
Materi 1. Pengantar Rekayasa Perangkat Lunak

4. Tidak ada representasi yang benar-benar geometris, tidak seperti rencana untuk
bangunan atau gambar desain mesin, dapat mewakili desain sebuah program
perangkat lunak.
Brooks, Jr berpendapat bahwa terobosan masa lalu, seperti bahasa tingkat tinggi,
pembagian waktu fasilitas, dan lingkungan pemrograman pemersatu (seperti Unix),
hanya menyerang yang tidak disengaja masalah rekayasa perangkat lunak, bukan yang
esensial. Dia juga skeptis tentang kemampuan seperti itu perkembangan sebagai
kemajuan dalam bahasa tingkat tinggi lainnya, pemrograman berorientasi objek, buatan
intelijen, sistem pakar, pemrograman otomatis, verifikasi program, lingkungan
pemrograman dan alat-alat, dan workstation dalam memecahkan masalah-masalah
penting dari rekayasa perangkat lunak. Brooks, Jr. menyarankan bahwa perkembangan
berikut memiliki potensi tinggi dalam mengatasi masalah mendasar dari rekayasa
perangkat lunak:

1. Beli daripada membangun. Komponen yang diuji sudah dikembangkan dan

digunakan adalah yang terbaik kandidat untuk digunakan kembali dalam produk
perangkat lunak baru. Mereka akan bebas dari kesalahan. Namun demikian
komponen harus dipilih dan harus terintegrasi dengan perangkat lunak baru. barang
sedang dikembangkan.
2. Penyempurnaan persyaratan dan pembuatan prototipe cepat. Prototyping adalah
metode yang sangat berguna dapatkan persyaratan informasi pengguna. Ini
membantu untuk mengetahui persyaratan inti yang kemudian disempurnakan
ketika prototipe baru ditampilkan kepada pengguna.
3. Pengembangan inkremental. Mengembangkan persyaratan fungsional inti dan
kemudian secara bertahap menambahkan fungsi lain memegang kunci untuk
mengembangkan produk perangkat lunak bebas kesalahan.
4. Desainer kreatif. Perusahaan perangkat lunak harus mempertahankan desainer
terbaik dan paling terampil karena mereka memegang kunci untuk mengeluarkan
produk perangkat lunak berkualitas.

G. MITOS PERANGKAT LUNAK

18 | A n a l i s i s P e r a n c a n g a n P e a n g k a t L u n a k
 Materi 1. Pengantar Rakayasa Perangkat Lunak|

Pressman (1992) telah menyusun mitos berikut yang berlaku di industri

perangkat lunak:

1) Mitos Manajemen:
a. Kami sudah memiliki buku yang penuh dengan standar dan prosedur untuk
membangun perangkat lunak. Biasa yang memberi orang saya segala yang
perlu mereka ketahui?
b. Orang-orang saya memang memiliki alat pengembangan perangkat lunak
canggih; setelah semua, kami membelinya komputer terbaru.
c. Jika kita terlambat, kita bisa menambah lebih banyak orang dan mengejar
ketinggalan.
2) Mitos Pelanggan:
a. Pernyataan tujuan secara umum sudah cukup untuk mulai menulis program —
kita dapat mengisi detailnya nanti.
b. Persyaratan proyek terus berubah, tetapi perubahan dapat dengan mudah
diakomodasi karena perangkat lunaknya fleksibel.
3) Mitos Praktisi:
a. Setelah kami menulis program dan mulai bekerja, pekerjaan kami selesai.
b. Sampai saya mendapatkan program “berjalan,” saya benar-benar tidak memiliki
cara untuk menilai kualitasnya.Satu-satunya hasil pengiriman untuk proyek
yang berhasil adalah program kerja. Ketika alat dan teknik rekayasa perangkat
lunak dikembangkan dan dipraktikkan, mitos ini memiliki diberikan cara untuk
kepedulian yang tulus untuk alat pengembangan baru dan keinginan yang kuat
untuk mengenal mereka. Itu bab berikut menjelaskan mereka dengan contoh
dan dengan referensi untuk pengembangan mereka dari masa lalu hingga
sekarang.

A n a l i s i s P e r a n c a n a n P e r a n g k a t L u n a k | 19