I. Pengantar
♦ Definisi :
Perancangan perangkat lunak adalah disiplin manajerial dan teknis yang berkaitan
dengan pembuatan dan pemeliharaan produk perangkat lunak secara sistematis,
termasuk pengembangan dan modifikasinya, yang dilakukan pada waktu yang tepat
dan dengan mempertimbangkan faktor biaya.
♦ Tujuan :
Tujuan perancangan perangkat lunak adalah untuk memperbaiki kualitas produk
perangkat lunak, meningkatkan produktivitas, serta memuaskan teknisi perangkat
lunak.
♦ Pengertian produk perangkat lunak :
Produk perangkat lunak adalah perangkat lunak yang digunakan oleh berbagai
pengguna, bukan untuk pengguna pribadi.
♦ Hal-hal yang perlu diperhatikan dalam pengembangan sebuah produk
perangkat lunak :
• kebutuhan dan batasan-batasan yang diinginkan pengguna harus ditentukan dan
dinyatakan secara tegas,
• produk perangkat lunak harus dirancang sedemikian rupa sehingga mampu
mengakomodasi paling tidak kepentingan tiga pihak berikut : pelaksana
implementasi, pengguna, dan pemelihara produk,
• penulisan source code harus dilakukan dengan hati-hati dan senantiasa melalui
tahap uji,
• dilengkapi dengan dokumen-dokumen pendukung seperti : prinsip pengoperasian,
user’s manual, instruksi instalasi, dokumen pemeliharaan,
• menyiapkan bantuan pelatihan.
♦ Tugas-tugas pemeliharaan perangkat lunak meliputi :
• analisa terhadap permintaan perubahan,
• perancangan ulang dan modifikasi terhadap source code yang diikuti dengan
serangkaian proses uji,
• dokumentasi perubahan dan pembaruan dokumen-dokumen yang berkaitan
dengan modifikasi,
• penyebaran produk yang telah mengalami modifikasi ke situs-situs pengguna.
♦ Jarak inteletual
• Pemetaan antara model dengan realitas yang dimodelkan dikenal sebagai jarak
intelektual antara suatu persoalan dengan komputerisasi solusi atas persoalan
tersebut.
• Prinsip dasar perancangan rekayasa perangkat lunak adalah merancang produk
perangkat lunak yang meminimalkan jarak intelektual.
♦ Modul
• Prinsip dasar untuk menangani kerumitan dalam perancangan perangkat lunak
adalah dengan melakukan dekomposisi terhadap sistem yang berukuran besar ke
dalam beberapa subsistem yang lebih kecil.
• Unit dekomposisi tersebut dinamakan modul.
• Dalam dekomposisi tersebut harus ditetapkan pengantarmukaan (interfacing)
antar setiap subunit, baik pengantarmukaan kendali maupun data.
• Pengantarmukaan kendali dilakukan dengan mekanisme hubungan pemanggilan
(calling) antar modul.
• Pengantarmukaan data dilakukan dengan mekanisme penyampaian parameter
(parameter passing) antar modul.
♦ Programmer
Programer adalah individu yang bertugas dalam hal rincian implementasi,
pengemasan, dan modifikasi algoritma serta struktur data, dituliskan dalam sebuah
bahasa pemrograman tertentu.
♦ Software Engineer
• Software engineer bertugas melakukan analisa, rancangan, uji dan verifikasi,
dokumentasi, pemeliharaan perangkat lunak, serta pengelolaan proyek.
• Software engineer harus mempunyai keterampilan dan pengalaman seorang
programmer
♦ Kualitas Produk Perangkat Lunak
Beberapa atribut yang merupakan ukuran kualitas perangkat lunak adalah :
• kegunaan, yaitu pemenuhan terhadap kebutuhan pengguna,
• keandalan, yaitu kemampuan melaksanakan fungsi yang diinginkan,
• kejelasan, yaitu penulisan program dilakukan secara jelas dan mudah dimengerti,
• efisiensi, terutama dalam waktu eksekusi dan penggunaan memory,
40
Pemeliharaan s/w
20
0
1955 1960 1978 1985
Perubahan rasio biaya untuk h/w terhadap biaya untuk s/d 1985
♦ Distribusi Upaya
• Masa hidup sebuah produk perangkat lunak adalah 1 s/d 3 tahun dalam
pengembangan dan 5 s/d 15 tahun dalam pemakaiannya (pemeliharannya).
• Distribusi upaya antara pengembangan dan pemeliharaan bervariasi antara 40/60,
30/70, dan bahkan 10/90.
• Tiga aktivitas pengembangan perangkat lunak adalah : analisa dan perancangan,
implementasi dan pengujian.
• Tiga aktivitas pemeliharaan perangkat lunak adalah : peningkatan kemampuan
produk, penyesuaian produk dengan lingkungan pemrosesan baru, dan perbaikan.
36%
16% 16%
8% 12% 12%
40% Proyek 2
30
20
10
A. Pendefinisian Masalah
1. Nyatakan masalah yang akan diselesaikan secara tegas, termasuk di dalamnya batasan
masalah dan sasaran yang ingin dicapai. Pernyataan masalah ditetapkan dalam sudut
pandang pelanggan.
• pernyataan masalah dalam sudut pelanggan misalnya : masalah penggajian,
masalah inventory, atau masalah pengendalian lalu lintas udara
• pernyataan masalah dalam sudut pengembang misalnya : masalah relational data
bases, masalah algoritma sorting.
• Teknik-teknik yang digunakan untuk mendapatkan informasi kebutuhan
pelanggan meliputi : wawancara dengan pelanggan, pengamatan terhadap gugus
tugas yang bermasalah, kinerja sebenarnya dari gugus tugas.
2. Rancang sebuah strategi solusi berbasis komputer.
• Solusi harus ekonomis dan dapat diterima secara sosial maupun secara politik.
• Solusi yang ekonomis adalah sistem komputerisasi yang memberikan pelayanan
dan informasi yang sama dengan sistem lama tetapi membutuhkan waktu dan
personal yang lebih sedikit dalam pengoperasiannya.
• Sistem baru mungkin akan mengurangi keterlibatan personal; hal ini mungkin
akan menimbulkan dampak sosial, bahkan politik.
3. Identifikasi sumber daya yang tersedia.
• Tiga subsistem dalam sistem komputerisasi adalah : perangkat keras, perangkat
lunak, dan personal. Identifikasi juga keterkaitan antar ketiga subsistem tersebut.
• Subsistem perangkat keras meliputi perangkat keras beserta periferalnya, dan
dalam beberapa kasus juga meliputi peralatan lain seperti sensor kendali proses,
antena, dan radar.
• Subsistem perangkat lunak meliputi perangkat lunak yang akan dikembangkan
ditambah dengan perangkat lunak yang ada yang boleh jadi digunakan seadanya
atau dalam versi modifikasinya.
• Subsistem personal meliputi para operator, pemelihara, dan end user.
4. Tetapkan sasaran dan persyaratan, baik untuk proses pengembangan maupun produk.
• Sasaran adalah tujuan yang ingin dicapai. Sasaran digunakan sebagai dasar bagi
kerangka kerja proyek pengembangan perangkat lunak, baik dalam proses
pengembangan maupun untuk produk kerja.
• Sasaran dapat dinyatakan secara kualitatif maupun kuantitatif. Contoh :
♦ proses (kualitatif) : harus meningkatkan keterampilan personal
♦ proses (kuantitatif) : sistem harus selesai dalam 12 bulan
♦ produk (kualitatif) : sistem harus membuat pekerjaan user maikin menarik
♦ produk (kuantitatif) : sistem harus mengurangi biaya transaksi sebesar 25%.
• Persyaratan menetapkan spesifikasi kemampuan sistem dalam menyelesaikan
masalah.
• Persyaratan mencakup aspek-aspek : fungsional, kinerja, perangkat keras,
perangkat lunak, personal, dan pengantarmukaan.
• Kalau memungkinkan, nyatakan persyaratan secara kuantitaif untuk menghindari
ketidakjelasan dan perselisihan antara pengembang dengan pelanggan.
• Contoh persyaratan kuantitatif :
♦ akurasi sudut fase harus berada pada kisaran 0.5 derajat
♦ tanggapan maksimum terhadap interrup adalah 0.25 detik
♦ space maksimum yang digunakan sistem adalah 50 KB memori utama, tidak
termasuk space untuk file-file buffer
♦ sistem harus dapat beroperasi dengan kemampuan 95% ketika dioperasikan
selama 24 jam penuh
• Contoh persyaratan kualitatif :
♦ akurasi harus cukup tinggi
♦ sistem harus mempunyai tanggapan yang baik
♦ sistem harus hemat dalam penggunaan memori utama
♦ keandalan sistem harus 99%
• Sasaran dan persyaratan dapat juga ditetapkan melalui atribut-atribut kualitas
yang harus dimiliki sistem, di antaranya : portability (S/W tidak bergantung
mesin), realiability (kemampuan program melakukan fungsi yang diinginkan),
efficiency (menggunakan sumber daya minimal), accuracy (ukuran besarnya
error), robustness/integrity (kemampuan bekerja dengan baik walau mendapat
input yang tidak benar), correctness (hasil sesuai dengan yang diharapkan).
5. Tetapkan kriteria penerimaan sebuah sistem
• Kriteria harus dinyatakan sedemikian rupa sehingga tidak akan menimbulkan
perselisihan antara pengembang dan pelanggan. Kriteria harus dapat diverfikasi
dengan suatu metoda baku seperti : peninjauan langsung, analisa, atau
serangkaian uji, terhadap produk yang dihasilkan.
Life Cycle
Life-cycle sebuah perangkat lunak mencakup semua kegiatan yang yang perlu dilakukan
untuk mendefinisikan, mengembangkan, menguji, mengantarkan, mengoperasikan, dan
memelihara produk perangkat lunak. Beberapa model yang akan dibahas adalah : model
fase (phased model), model biaya (cost model), model prototipe (prototype model), dan
model berurutan (successive model).
Model Fase
Model ini membagi life cycle ke dalam sederetan kegiatan (fase). Setiap fase
membutuhkan informasi masukan, proses, dan produk yang terdefinisi dengan baik.
Deretan fase tersebut adalah : analisa, perancangan, implementasi, pengujian, dan
pemeliharaan. Berikut ini model fase dasar yang dinyatakan sebagai waterfall chart :
Analisis Perancangan Implementasi Pengujian Pemeliharaan
-perencanaan
-penetapan
persyaratan
arsitektur
rinci
verifikasi
coding, debugging,
dan uji code
verifikasi
- uji integrasi
- uji penerimaan
verifikasi
verifikasi - peningkatan
- adaptasi
- perbaikan
verifikasi - peningkatan
- adaptasi
- perbaikan
Model Prototipe
Authorize
Feasibilty
Study
Preliminary Preliminary
Requirements Requirements
Analysis Spesification
Autorize
Prorotype
Prototype
Formal Preliminary Implementation Implementation Preliminary
Equirements Design Design Plan Test Plan
Spesification Spesification Code
Test
Demo
Authorize
Project
Final
Validation Evaluation
Report
Product
Release
Beberap catatan tentang model prototipe :
• Sebuah prototipe adalah model dari sebuah produk perangkat lunak tetapi dengan
beberapa keterbatasan, misalnya : keterbatasan kemampuan, keandalan yang rendah,
dan kinerja yang tidak efisien.
• Alasan penggunaan model prorotipe adalah :
1. untuk menggambarkan format data masukan, pesan-pesan, laporan, dan dialog
interaktif
2. untuk mengeksplorasi isu-isu teknis dalam produk yang diusulkan
3. model fase ‘analisis → perancangan → implementasi’ tidak dapat digunakan
Versi Succesive
Design Design
Versi I Versi I
I = 1..N
Build
Version I Build
Version I
Assess
Version I Assess
Version I
No
Good ? No
I=N?
Maintenance
Maintenance
Product
manager 1
Subproject 1 Subproject 1 Subproject 1 Subproject 1 Subproject 1
Product
manager 2
Subproject2 Subproject 2
Product
manager 3
Subproject3 Subproject 3 Subproject3
Struktur Tim Pemrograman
Demokrasi
Kepemimpinan
pimpinan
Pustakawan
back-up
programmer
Programer
1.1 Boehm
1.0
0.5 0.75 1.0 1.25 1.5
TMod
0.9 Jadwal Relatif =
TNor
• Menurut Putnam upaya proyek S/W berbanding terbalik dengan pangkat empat dari
waktu pengembangan, yaitu : PM = k/((TDEV) 4 ).
• Berdasarkan formula Putnam maka perpanjangan jadwal 2 kali jadwal normal akan
menurunkan upaya 100 programmer dalam satu bulan menjadi : (100/2 4 ) = 6.25
programmer. Lebih tidak masuk akal bahwa lagi upaya akan menjadi nol jika jadwal
pengembangan menjadi tak hingga.
• Putnam juga mengisyaratkan bahwa kompresi jadwal terbatas sampai 86% jadwal
normal, walaupun menurut formulanya kompresi sebesar ini hanya akan menaik-kan
jumlah personal sebesar 1.82 kalinya.
• Melalui penelitian terhadap 63 proyek perangkat lunak, Boehm mencatat bahwa
hanya 4 proyek yang memungkinkan dilakukannya kompresi jadwal menjdi kurang
dari 75% jadwal awal. Berdasarkan penelitian ini Boehm menyatakan bahwa
kompresi terhadap jadwal tidak dapat dilakukan di bawah 75%.
5. Tingkat Keandalan Yang Diperlukan
Lima katagori keandalan, efek kegagalan, beserta pengali upaya (effort multiplier)
pengembangan yang direkomendasikan Boehm ditunjukkan melalui tabel berikut :
Katagori Efek kegagalan Pengali upaya
Sangat rendah tidak nyaman digunakan 0.75
Rendah kesalahan mudah dipulihkan 0.88
Nominal tidak terlalu sulit memulihkan kesalahan 1.00
Tinggi kerugian finansial tinggi 1.15
Sangat tinggi resiko terhadap kehidupan manusia 1.40
6. Tingkat Teknologi
• Tingkat teknologi dalam proyek pengambangan S/W direfleksikan dengan empat
komponen yang digunakan, yaitu : (1) bahasa pemrograman, (2) mesin abstrak (H/W
dan S/W), (3) praktek-praktek pemrograman, dan (4) tools
• Bahasa Pemrograman : Sebaris statement program dalam high level language identik
dengan beberapa baris statement dalam low level language, dengan demikian
penggunaan high level language akan menaikkan produktivitas 5 sampai 10 kalinya.
• Mesin Abstrak : Mesin abstrak adalah sekumpulan fasilitas H/W dan S/W yang
digunakan selama proses pengembangan. Produktivitas akan buruk jika programmer
harus belajar lebih dahulu mesin dan lingkungan baru sebagai bagian dari proses
pengembangan.
• Praktek-Praktek Pemrograman : Praktek pemrograman modern meliputi : (1) analisis
sistematik dan teknik-teknik perancangan, (2) notasi perancangan terstruktur, (3)
pemeriksaan, (4) pengkodean (coding) terstruktur, (5) pengujian yang sistematis, dan
(6) perpustakaan pengembangan program.
• Tools : Tools yang berwujud S/W terdiri dari : assembler dan debugger, compiler dan
linker, DBMS, dan tools lain yang lebih advanced.
• Pengali upaya dalam praktek pemrograman yang direkomendasikan Boehm bervariasi
antara 1.24 (tanpa praktek pemrograman modern) sampai 0.82 (sepenuhnya
menggunakan praktek pemrograman modern), antara 1.24 (menggunakan tools dasar
seperti compiler dan debugger) sampai 0.83 (menggunakan tools pengembangan yang
paling advanced).
3.2. Teknik-teknik perkiraan biaya S/W
• Perkiraan biaya S/W seringkali bersandar kepada data historis.
• Perkiraan biaya bisa dilakukan secara top-down atau bottom-up.
• Top-down : fokus pertama adalah perkiraan biaya tingkat sistem seperti sumber daya
komputasi, personal yang diperlukan, pengaturan konfigurasi perangkat lunak,
jaminan kualitas, integrasi sistem, pelatihan, dan publikasi.
Bottom-up : fokus pertama adalah perkiraan biaya pengembangan setiap modul atau
subsistem, sedemikian rupa sehingga sampai pada perkiraan biaya sistem secara
keseluruhan.
• Teknik top-down sangat baik dalam memandang sistem secara keseluruhan, tetapi
kadang-kadang melupakan berbagai masalah teknis pada pengembangan beberapa
modul.
• Teknik bottom-up menekankan perkiraan biaya setiap modul, tetapi kadang-kadang
gagal dalam mengakomodasi perkiraan biaya level sistem seperti pengaturan
konfigurasi perangkat lunak dan jaminan kualitas.
1. Pendapat Pakar (Expert Judgment)
• Teknik ini merupakan teknik perkiraan biaya yang sering digunakan yang juga
merupakan teknik top-down.
• Contoh proses perkiraan seorang pakar adalah sbb.:
i. Sistem yang akan dikembangkan adalah sebuah sistem kendali proses yang mirip
dengan sistem yang dikembangkan tahun lalu dengan biaya US$ 1 juta dan waktu
10 bulan.
ii. Tidak ada pembengkakan biaya (mark-up) tetapi mempertimbangkan keuntungan
yang cukup baik.
iii. Diinginkan sistem yang mempunyai fungsi kendali 25% lebih aktif sehingga
perkiraan waktu dan biaya akan dinaikkan sebesar 25%.
iv. Dalam pengambangan tersebut digunakan komputer dan peralatan lain serta
personal yang sama dengan yang digunakan pada pengembangan sistem
sebelumnya sehingga perkiraan biaya dapat direduksi sebesar 20%.
v. Kita dapat memanfaatkan cukup banyak code produk sebelumnya sehingga
mereduksi waktu dan biaya sebesar 25%.
vi. Berbagai pertimbangan di atas menghasilkan perkiraan sebesar :
Biaya : 125% × US$ 1 juta × 80% × 75% = US$ 750 ribu
Waktu : 125% × 10 bulan × 75% = 9.4 bulan
vii. Untuk nyamannya kita bisa melakukan pengajuan proyek sebesar US$ 850 ribu
dalam 10 bulan.
√ √ Programmer-months
0 20 40 60 80 100
Nilai Median
Nilai perkiraan anda untuk putaran berikutnya : 35 PM
Process
QA
0 1 2 Waktu
Perancangan dan Manajemen (10%) Pemeliharaan (20%)
Coding (15%)
• Setiap kurva memenuhi persamaan Rayleigh :
2 2
K -t 2t d
E= 2te
td
t d adalah waktu ketika kurva mencapai puncak. K adalah luas daerah di bawah kurva
yang menyatakan total upaya yang diperlukan untuk proyek pada fase tersebut, kira-
kira 40 % di kiri t d dan sisanya di kanan t d .
• Putnam menafsirkan bahwa t d berkaitan dengan waktu pengujian sistem dan
pemasaran produk. Tafsiran Putnam ditunjukkan pada gambar 3.8.
Boehm mengamati bahwa kurva Rayleigh dapat didekati dengan melibatkan faktor PM
dan TDEV sehingga persamaannya menjadi :
(0.15×TDEV + 0.7 t ) 2
0.15 × TDEV + 0.7 t − 0.5×(TDEV) 2
FSP = PM × ×e
0.25 × (TDEV)2
dimana FSP = full-time software personal.