DUNIA KOMPUTER

semua informasi tentang komputer

Beranda
About this web

DESAIN
PROSEDURAL
PERANGKAT LUNAK

REKAYASA

Februari 20, 2008

PENDAHULUAN
Desain prosedural terjadi setelah data, desain arsitektur, dan
interface, dibangun.Dalam dunia yang ideal, spesifikasi prosedural diperlukan
untuk menetapkan detail algoritma yang akan dinyatakan dalam suatu bahasa
ibu seperti bahasa inggris. Akan tetapi, semua anggota organisasi
pengembangan perangkat lunak menggunakan bahasa ibu (paling tidak
secara teori), orang di luar domain perangkat lunak dapat lebih memahami
spesifikasi tersebut dan tidak ada pelajaran baru yang di perlukan.
Sayangnya ada satu masalah kecil, desain prosedural harus menentukan
detail desain prosedural tanpa ada ambiguitas, dan tidak ada ambiguitas. Di
dalam bahasa ibu bukan merupakan hal hal wajar. Dengan menggunakan
suatu bahasa ibu, kita dapat menuliskan serangkaian langkah prosedural
dalam begitu banyak cara yang berbeda. Kita kerap kali bersandar pada
konteks untuk mendapatkan fakta penting. Kita sering menulis seolah-olah
ada dialog dengan pembaca (sebenarnya tidak). Karena alasan tersebut dan
hal lainnya, harus digunakan mode yang lebih terbatas untuk
mempresentasikan detail prosedural
PEMROGRAMAN TERSTUKTUR REKAYAS PERANGKAT LUNAK
Definisi definisi mendasar dari pemrograman yang terstruktur adalah
sebagai berikut :

Teori pemrograman terstruktur memperlakukan pengkorversian

diagram alir besar dan kompleks ke dalam bentuk standar sedemikian
rupa sehingga mereka dapat dipresentasikan dengan iterasi dan

nesting (pengumpulan) sejumlah kecil struktur logika kontrol dasar dan

standar (H.D. Mills, Chief Programmer Teams:Principle and
Procedures).
Pemrograman terstruktur adalah cara pengorganisasian dan
pengkodean program-program yang kompleks dan membuat program
tersebut
lebih
mudah
dipahami
dan
dimodifikasi
(J.R.Donaldson,Struktured programming
Konsep dasar [dari pemrograman terstuktur] adalah suatu pembuktian
kebenaran, (R.A.Karp)
Pemrograman terstuktur bukanlah obat mujarab-ia benar-benar terdiri
dari suatu atribut yang biasanya tidak inherent (menjadi sifat) dalam
pemrograman atau sebarang jenis yang lain (D.Butterworrth)
Prof E.W Dykstra pada tahun 1960 dalam papernya mengusulkan

bahwa pernyataan Go To,seharusnya tidak dipergunakan didalam program

terstuktur. Oleh karena itu sering disebut pemrograman terstruktur sebagai
pemrograman tanpa GOTO (GOTO less programming).
Definisi yang lain oleh H.D. Mills adalah pemrograman terstuktur tidak harus
dicirikan secara panjang lebar dengan absennya go to,melainkan timbulnya
terstruktur.
Sedangkan definisi yang lebih akurat lagi dinyatakan oleh N. Wirth bahwa
pemrograman terstuktur adalah formulasi program secara hierarkis,struktur
berkelompok
Pernyataan

dari
Wirth

pernyataan-pernyataan
sendiri

bukanlah

dan

objek-objek

mendefininisikan

komputasi.

perangkat

atau

konstruksi kontrol logika yang dapat digunakan, atau tidak membatasi teknik
formulasi terstuktur yang tersedia untuk desain program.
Prinsip utama dari pemrograman yang terstuktur adalah bahwa jika
urutan suatu proses telah sampai pada suatu baris sintaks tertentu, maka
proses selanjutnya tidak boleh melompat mundur kebaris sebelumnya,
kecuali untuk proses dengan struktur kontrol repetition/looping. Modifikasi
akan sulit dilakukan terhadap suatu program, jika kode programnnya yang
dibuat tidak terstruktur dengan baik. Biasanya para pemrogram (programmer)
akan merasa sangat perlu untuk memahami metodologi perancangan
program yang terstruktur, jika mereka sedang membuat program yang besar
dan komplek.

Pemrograman terstruktur dipandang oleh banyak pemrogram sebagai

sinonim

untuk

pemrogramman

modular

atau

top-down.

Sebenarnya

pemrograman modular adalah suatu sub kelas dari metodologi perancangan

dalam suatu kelas umum dari metodologi penyederhanaan persoalan yang
diketahui sebagai pemrograman terstruktur.
Pemrograman terstuktur dapat divisualisasikan sebagai aplikasi dan
metode penyederhananaan persoalan dasar untuk menyusun terstruktur
persoalan hierarki yang bisa dikelola.Untuk memperolah suatu pengetahuan
yang lebih besar dari perbedaan antara sub kelas berbagai metodologi yang
terkandung dalam pemrograman terstruktur, pertama kita harus memandang
tujuan dari proses kemurnian. Kita diberikan suatu persoalan, biasanya kita
menspesifikasi kedalam bahasa kita, dan mensyaratkan untuk menunjukan
suatu penyelesaian persoalan tersebut ke dalam suatu bahasa pemrograman
tingkat tinggi.
Bila persoalan tidak lebih darimenghitung jumlah dari A dan B, persoalan ini
akan langsung diterjemahkan kedalam RESULT = A+B. Jika persoalan besar
atau rumit, maka sistem yang didefinisikan untuk menyelesaikan persoalan
tersebut haruslah disederhanakan menjadi sub sistem dimana setelah
sejumlah penyederhanaan, secara hierarkis menjadi modul-modul. Setelah
penyederhanaan tambahan, hasilnya merupakan suatu program yang
terstruktur. Masing-masing sub kelas metodologi dapat digambarkan dengan:

Jangkauan proses keaslian yang padanya metodologi menjadi efektif.

Pendekatannya ke proses keaslian.
Aplikasi yang berguna

CIRI-CIRI PROGRAM TERSTUKTUR

Program yang baik/terstuktur mempunyai ciri-ciri sebagai berikut :
Dapat dijalankan dengan baik dan benar (sesuai dengan keinginan
pemrogram).
Dapat dijalankan secara efisien dan efektif dengan tidak banyak
menggunakan sintaks yang tidak perlu (menghasilkan output yamg
tepat dan benar dalam waktu yang singkat).
Mudah dibaca dan dipahami oleh orang lain maksud dan tujuan objek
yang akan ditampilkan (memiliki logika perhitungan yang tepat dalam
memecahkan masalah, dan ditulis dalam bahasa yang standar yaitu
bahasa Indonesia/Inggris terstuktur,sehingga tidak menimbulkan arti
ganda).
Mudah diperbaiki, jika terjadi kesalahan (semua operasi yang
dilakukan harus terdefinisi dengan jelas dan berakhir setelah sejumlah
langkah dilakukan).

Biaya pengujian yang dibutuhkan rendah

Memiliki dokumentasi yang baik
Biaya perawatan dan dokumentasi yang dibuthkan rendah
Program hanya terdiri dari tiga struktur kontrol, yaitu stuktur urut,stuktur
seleksi, dan struktur repetisi/iterasi

LANGKAH-LANGKAH PENGEMBANGAN PROGRAM

Suatu program yang baik membutuhkan suatu standar, sehingga akan
memudahkan pemrogram untuk merancang, dan merawat program. Sehingga
perlu dipahami beberapa langkah yang harus dilakukan dalam merancang
suatu program yang terstruktur. Langkah langkah tersebut adalah sebagai
berikut:
1. Definisikan Masalah
Pemahaman permasalahan merupakan suatu hal yang sangat
penting bagi sipemrogram. Sipemrogram perlu memahami permasalahan
yang dihadapi dan yang akan diselesaikan oleh pemesan program, agar
hasil pendefinisian masalah tidak menyimpang dari masalah yang sedang
dihadapi.
Setelah menyamakan persepsi tentang suatu masalah yang
dihadapi dan akan diselesaikan, maka pemrogram dapat mengidentifikasi
permasalahan tersebut secara rinci, dan menentukan ruang lingkup
permasalahan yang akan diselesaikan terlebih dahulu, dan kemungkinan
kendala-kendala

yang

akan

dihadapi,

lalu

berapa

lama

proses

penyelesaian masalah tersebut. Pemrograman harus membuat langkahlangkah penyelesaian masalah berdasarkan ruang lingkup permasalahan
yang ditentukan, sehingga pekerjaan pembuatan program terarah dan
terjadwal dengan baik.
Masalah yang perlu didefinisikan adalah komponen input dari suatu
program yang akan dirancang tersebut apa saja yang akan terjadi didalam
menyelesaikan program tersebut dan menampilkan hasilnya, yang terakhir
adalah komponen output yang diinginkan seperti apa, dan formatnya
bagaimana.

2. Merancang Outline Pemecahan Masalah

Dalam merancang outline pemecahan masalah pemrogram perlu
membuat rincian proses secara rinci (meliputi proses apa saja yang terjadi
pada menu utama, lalu masing-masing sub menu dalam menu utama
tesebut akan mengerjakan berapa proses,setiap proses yang terjadi
berinteraksi dengan file apa saja, dan berapa file yang terlibat dalam
proses tersebut).
Setelah rincian proses dan file yang berinteraksi diketahui,
pemrogram menentukan berapa bentuk stuktur kontrol yang terlibat dalam
satu proses,dan jenis stukturnya apa saja dan berapa banyak, misalkan
baris 1-10 menggunakan struktur urut atau seleksi, dan baris 11-20
menggunakan struktur repetisi repeat-until atau for-do, dst.
Judul dari setiap proses (modul) apa saja, dan deklarasikan seluruh
variable yang akan digunakan dalam setiap proses (modul), baik variable
lokal maupun variable global. Setelah itu tentukan deskripsi dari proses
(modul) tersebut. Setelah outline selesai, maka transformasikan outline
tersebut kedalam algoritma, dengan menggunakan pseudecode yang
dapat ditulis dengan struktur Indonesia (bahasa Indonesia terstuktur) atau
struktur Inggris (bahasa Inggris tersrtuktur).
Desain algoritma yang dibuat haruslah sama dengan langkahlangkah penyelesaian masalah yang ditentukan, karena algoritma dibuat
untuk menyelesaikan masalah yang dihadapi oleh pemrogram.
Algoritma yang telah dibuat tersebut perlu dilakukan pengujian agar
output yang

dihasilkan nantinya

dapat sesuai dengan keinginan

sipemrogram. Disamping pengujian juga perlu dibuat format input / output

yang jelas, serta komentar untuk setiap baris yang dapat membantu
pemrogram dalam mengingat tujuan dari perintah tersebut.Pengujian
algoritma tersebut dapat dilakukan dengan menggunakan diagram
overview dan diagram rinci HIPO (HIRARKI Plus Input dan Output).

3. Pengkodean Program
Algoritma yang telah selesai dilakukan pengujian,dapat langsung
ditransformasikan kedalam salah satu bahasa pemrograman yang
diinginkan atau yang dikuasai oleh sipemrogram. Bahasa pemrograman
yang baik harusalah dapat dipakai pada berbagai jenis komputer yang
berbeda-beda dan berbaai jenis sistem informasi, hal ini dikenal dengan
portabilitas. Pemrogram juga haruslah menentukan batas waktu minimum
dalam

penulisan

suatu

modul

program,

dari

awal

hingga

siap

dioperasikan.
Tujuan pengkodean adalah terjadinya efisiensi terhadap memori
yang akan digunakan, efisiensi perintah dalam setiap modul program,serta
efisiesi terhadap penggunaan fasilitas input dan output yang akan
berpengaruh langsung terhadap porseor ataupun terhadap pengguna.
4. Eksekusi Program
Pekerjaan komputer (prosesor) pada dasarnya hanya dua yaitu fetch
(membaca instruksi/ program dari memori), lalu execute (mengeksekusi
instruksi/program tesebut) dan menampilkan hasilnya ke media output
seperti printer, monitor dll.Untuk memperoleh eksekusi program dengan
kecepatan maksimum, maka perlu diperhatikan beberapa faktor, seperti
jenis bahasa pemrograman yang dipilih apakah sanggup mengangkat data
yang akan diproses, dan spesifikasi perangkat keras yang digunakan.
5. Dokumentasi Dan Pemeliharaan Program
Penulisan program yang kompleks harus selalu didokumentasikan
setiap kurun waktu tertentu, jadwal dokumentasi juga perlu dibuat demi
menjaga keamanan terhadap program dan data dari orang-orang yang
tidak bertanggung jawab.
Pemeliharaan program berfungsi untuk menjabarkan aktivitas dari
hasil

analisis

terhadap

sistem

dan

dilakukan

setelah

program

diimplementasikan dan telah digunakan beberapa saat oleh pemakai.

Pemeliharaan mencangkup:
1. Format tampilan yang disesuaikan dengan keinginan pengguna
2. Fungsi-fungsi yang tidak sesuai dengan keinginan pengguna
3. Adaptasi dengan spesifikasi prosesor yang baru dan ssistem operasi
yang baru.
4. Dan lain-lain.
KOMPONEN PEMROGRAMAN TERSTUKTUR
Pemrograman terstuktur memiliki tiga komponen utama yaitu :.
1. Pemrograman Top-Down
Teknik Top-Down didefinisikan sebagai suatu masalah yang
kompleks dibagi-bagi kedalam beberapa kelompok masalah yang lebih
kecil. Dari kelompok masalah yang kecil tersebut dianalisis. Apabila
dimungkinkan, maka masalah tersebut akan dipilah-pilah lagi menjadi sub
bagian yang lebih kecil, dan setelah itu mulai disusun langkah-langkah
untuk menyelesaikan secara detail.
Bila ada masalah yang kompleks, maka pemecahan masalah
dilakukan dengan menggabungkan prosedur-prosedur yang ada menjadi
satu kesatuan program guna menyelesaikan masalah tersebut, teknik ini
dikenal dengan Teknik Bottom-Up yang sudah mulai ditinggalkan
pemrogram karena kurang efektif.
2. Pemrograman Modular
Pada teknik top-down masalah yang besar dan kompleks dibagibagi kedalam kelompok masalah yang lebih kecil. Kelompok masalah
yamg lebih kecil tersebut dinamakan modul. Satu modul akan mewakili
satu rincian proses detail yang sudah mewakili media penyimpanan dan
struktur data yang jelas.
Teknik

pemrograman

mengimplemetasikan

terstruktur

langkah-langkah

yang

pemecahan

digunakan
masalah

untuk
pada

kelompok masalah yang kecil tersebut dinamakan teknik pemrograman

modular.
Modul program didefinisikan sebagai sekumpulan instruksi yang
memiliki operasi-operasi dan data yang didefinisikan; memiliki stuktur
internal yang tidak tergantung pada subprogram yang lain, dan merupakan
satu kesatuan yang utuh yang akan dieksekusi secara berulang-ulang.
3. Teorema Struktur / Struktur Kontrol
Perancangan program terstruktur tidak dipengaruhi oleh kelebihan
dan keunggulan salah satu bahasa pemrograman yang sedang populer
pada saat itu, namun lebih dipengaruhi oleh tiga teorema struktur / struktur
kontrol yang akan digunakan. Karena pada dasarnya algoritma dari
program yang telah terstuktur akan dapat ditransformasikan kedalam
bahasa pemrograman dan jenis sistem informasi apa saja. Terdapat tiga
teorema struktur yaitu:
1. Struktur Urut
2. Struktur Seleksi
3. Struktur Repetisi/pengulangan.

Usaha untuk mengatasi permasalahan rekayasa

perangkat lunak

Februari 18, 2008

Masalah perangkat lunak (software engineering) biasanya dipilih berdasarkan 3 aspek

antara lain sifat dari proyek dan aplikasi, metode dan alat bantu yang digunakan serta
kontrol dan output yang dibutuhkan. Perekayasaan perangkat lunak berupa
penggunaan metode pengembangan perangkat lunak berkualitas tinggi secara
ekonomi dan handal. Dari usaha-usaha tersebut dihasilkan alternatif paradigma,
alternatif metodologi dan perangkat bantu komputer.
1. Siklus Hidup
Pengesetan dan piranti teknik serta metode yang digunakan oleh para ahli software
dalam proyek disebut Metodologi Proyek. Metodologi proyek diterapkan dalam
konteks tahap-tahap pengembangan software (software live cycle) , yang disebut fase,
yang merupakan tahapan yang harus dilalui oleh produk software dari konsep awal
sampai tahap akhir. Model tahap-tahap tersebt merupakan enyajian dari tahap-tahap
pengembangan software yang juga dapat berisikan alur informasi, saat penentuan
keputusan, dan sebagainya.
Langkah-langkah dari model tahapan penyusunan dapat merupakan fase temoporal
yang membentuk urutan dalam waktu atau fase logis yang menunjukkan tahap-tahap
bukan membentuk urutan temporal. Sebagai contoh implementasi secara logis akan
mendahului pengujian, namun bagian fase implementasi dan pengujian dapat terjadi
secara serempak. Jadi moedl tahapan yang menggunakan fase logis dapat memiliki
fase implementasi sebelum fase pengujian, sedangkan model yang menggunakan fase
temporal mungkin fase-fase ini kan bertumpang tindih.
2. Model Spiral
Permodelan dalam suatu perangkat lunak merupakan suatu hal yang dilakukan di
tahapan awal. Di dalam suatu rekayasa dalam perangkat lunak sebenarnya maih
memungkinkan tanpa melakukan suatu permodelan. Hal ini tidak dapat lagi dilakukan
dalam suatu industri perangkat lunak. Permodelan dalam perangkat lunak merupakan
suatu yang harus ikerjakan di bagian awal dari rekayasa, dan permodelan ini akan
mempengaruhi pekerjaan-pekerjaan dalam rekayasa perangkat lunak tersebut. dalam
prakteknya, setiap langkah sering tumpang tindih dan sering memberi informasi satu
ama lain.
Proses perangkat lunak tidak linier dan sederhana tapi mengandung urutan iterasi dari
aktivitas pengembangan. Selama langkah terakhir, perangkat lunak telah digunakan.
Kesalahan dan kelalaian dalam menentukan kebutuhan perangkat lunak original dapat
diatasi.
Namun sayang, model yang banyak mengandung iterasi sehingga membuat kesulitan
bagi pihak manajemen untuk memeriksa seluruh rencana dan laporan. Maka dari itu,
seteleh sedikit iterasi, biasanya bagian yang telah dikembangkan akan dihentikan dan
dilanjutkan dengan keinginan user. Mungkin juga sistem terstruktur secara jelek yang
sebenarnya merupakan masalah desain akan dibiarkan karena terkalahkan oleh trik
implementasi.

3. Pendekatan Waterfall
Model waterfall menawarkan cara pembuatan perangkat lunak secara lebih nyata.
Langkah-langkah yang penting dalam model ini adalah :

Penentuan dan analisis spesifikasi

Desain sistem dan perangkat lunak
Implementasi dan ujicoba unit
Integrasi dan uji coba sistem
Operasi dan pemeliharaan

Masalah pendekatan waterfall adalah ketidakluwesan pembagian project ke dalam

langkah yang nyata atau jelas. Sistem yang disampaikan kadang-kadang tidak dapat
digunakan sesuai keinginan customer. Namun demikian model waterfall
mencerminkan kepraktisan engineering. Konsekwensinya, model proses perangkat
lunak yang bredasarkan pada pendekatan ini digunakan dalam pengembangan sistem
perangkat lunak dan hardware yang luas.
4. Pendekatan Evolusioner
Pendekatan evolusioner ini berdasarkan pada ide pengembangan dan implementasi
awal yang akan menghasilkan komentar pemakai sehingga dapat dilakukan perbaikan
melalui banyak versi sampai sistem yang mencukupi dapat dikembangkan. Selain
memiliki kegiatan-kegiatan terpisah model ini memberikan umpan balik dengan cepat
dan serempak. Ada 2 tipe pada model ini yaitu :
a. Pemrogramaman evolusioner
Tujuan proses adalah bekerja sama dengan cusomer untuk menghasilakan kebutuhankebutuhan dan menyampaikan sistem akhir kepada pemakai/ customer.
Pengembangan dimulai dengan bagian-bagian sistem yang dimengerti. Sistem
dikembangkan melalui penambahan features sesuai yang diusulkan oleh customer. 2.
b. Pemodelan
Pemrograman evolusioner penting saat sulit untuk membuat spesifikasi sistem secara
rinci. Beberapa orang mungkin setuju bahwa semua sistem masuk dalam tipe ini.
Namun, pemrograman evolusioner banayk digunakan dalam pengembangan sistem
pakar (artifacial intelegence) yang berusaha untuk menyamai kemampuan manusia.
Kita tidak mungkin membuat spesifikasi yang rinci untuk perangkat lunak yang
menyamai manusia karena kita tidak mengerti bagaimana biasanya manusia
menjalankan tugas-tugasnya. Pendekatan evolusioner biasanya lebih efektif daripada
pendekatan waterfall untuk hal pengembangan perangkat lunak yang harus dengan
segera dapat memenuhi kebutuhan customer. Namun, daris egi teknik dan
manajemen, model ini mempunyai masalah mendasar yaitu :

proses tidak visibel

sistem biasanya kurang terstruktur
ketrampilan khusus jarang dimiliki

Untuk memecahkan masalah-masalah tersebut, kadang-kadang tujuan dari

pengembangan evolusioner adalah mengembangkan contoh sistem. Contoh ini
digunakan untuk mengerti dan memvalidasikan spesifikasi sistem. Disinilah
pengembangan evolusioner merupakan bagian dari beberapa proses yang lebih luas
(seperti model waterfall).
Oleh karena masalah-masalah tersebut, sistem dengan skala besar biasanya tidak
dikembangkan melalui cara ini. Pengembangan evolusioner lebih tepat untuk
pengembangan yang relatif kecil. Masalah-masalah mengenai perubahan sistem yang
ada dihindari dengan mengimplementasikan ulang sistem keseluruhan kapanpun
perubahan yang signifikan diperlukan. Jika permodelan digunakan, tidak terlalu
mahal. Pengembangan sistem yang memiliki masa hidup yang relatif singkat.
5. Spiral Boehm
Boehm (1988) mengusulkan sebuah model yang secara eksplisit menjelaskan bahwa
resiko yang disadari mungkin membentuk dasar model umum. Model yang diusulkan
oleh Boehm ini berbentuk spiral. Tak ada tahap yang ditetapkan dalam model ini.
Manajemen harus memutuskan bagaimana membentuk proyek ke dalam tahap-tahap.
Perusahaan biasanya bekerja dengan beberapa model umum dengan tambahan untuk
proyek khusus atau ketika masalah-masalah ditemukan selama pembuatan proyek.
Setiap loop dibagi dalam 4 sektor yaitu :

Pembuatan tujuan

Tujuan, hambatan dalam proses ataupun produk serta resiko-resiko proyek yang
ditentukan. Rencana rinci manajemen juga ditulis lengkap. Pembuatan strategistrategi alternatif direncanakan sesuai dengan resiko yang ada.

Perkiraan dan pengurangan resiko

Untuk setiap resiko yang telah diidentifikasi, akan dibuat analisis rincinya. Kemudian
diambil langkah-langkah untuk mengurangi resiko. Contohnya jika ada resiko bahwa
persayaratan-persyaratan tidak tepat maka sebuah model mungkin dapat
dikembangkan.

Pengembangan dan validasi

Setelah evaluasi resiko, jika resiko sebuah model pengembangan untuk sistem dipilih.
Misalnya, jika resiko interface pengguna yang dominan maka model pengembangan
yang tepat mungkin pengembangan evolusioner dengan menggunakan contoh
(prototype). Jika resiko keselamatan yang diutamakan, model pengembangan sesuai
adalah transformasi formal. Model waterfall mungkin tepat digunakan jika resiko
yang diutamakan adalah integrasi sistem.

Perencanaan

Jika diputuskan untuk melanjutkan pada loop spiral berikutnya, maka prosyek yang
dibicarakan kembalai dan rencana perlu dibuat untuk tahap selanjutnya. Tidak perlu
untuk menggunakan satu model tunggal pada setiap loop spiral bahkan dalam

keseluruhan sistem perangkat lunak. Model spiral encompasses model lainnya.

Pemodelan digunakan pada salah satu spiraluntuk memecahkan masalah kebutuhan.
Pada implementasinya, model spiral banyak digunakan , tetapi biasanya
dikombinasikan dengan model lain. Pemodelan waterfall yang sangat bagus dalam
menentukan milestones dan pemodelan spiral, yang sangat bagus dengan
menggunakan prototyping, merupakan kombinasi yang sering dipakai di dalam
kontrak-kontrak untuk perangkat lunak dewasa ini.