Anda di halaman 1dari 20

2

PENGEMBANGAN
PERANGKAT LUNAK
Tujuan
Bagian ini menj elaskan t entang pengembangan perangkat lunak, meliput i
pengertian, aktivit as, model proses, dan met ode pengembangannya. Set elah
mempelajari bagian ini dengan baik, pembaca diharapkan dapat:

Memahami arti pengembangan perangkat lunak.


Mengetahui akt ivitas pengembangan perangkat lunak.
Memahami model proses pengembangan perangkat lunak dan
mengetahui beberapa j enis model proses yang sering digunakan.
Mengetahui met ode pengembangan perangkat lunak.

Pokok Bahasan
Pokok bahasan pada bagian ini meliput i:

Proses Pengembangan Perangkat Lunak

Model Proses Pengembangan Perangkat Lunak

Akt ivitas Pengembangan Perangkat Lunak

Met ode Pengembangan Perangkat Lunak

19

20

BAGIAN I: KONSEP DASAR

Perangkat lunak sebagai sebuah produk rekayasa dihasilkan melalui


sekumpulan proses yang dilaksanakan menurut kerangka kerja t ert ent u. Salah
sat u proses yang sangat dominan dari rekayasa perangkat lunak adalah
pengembangan perangkat lunak (soft ware development ).

2.1 Proses Pengembangan Perangkat Lunak


Pengembangan perangkat lunak didefinisikan sebagai suat u proses dimana
kebut uhan pemakai diterj emahkan menjadi produk perangkat lunak melalui
suatu rangkaian aktivitas t ertent u sesuai model proses yang digunakan (lihat
Gambar 2.1).

Kebutuhan pemakai

Pengembangan
Perangkat Lunak

Perangkat lunak

Gambar 2.1 Proses Pengembangan Perangkat Lunak


Proses pengembangan perangkat lunak dilaksanakan set elah proses akuisisi dan
pasokan. Dalam pelaksanaannya, proses pengembangan ini akan melibatkan:

Orang (people)
Individu, kelompok, atau bagian organisasi yang menj adi pelaksana
pekerjaan, seperti analis sist em, pemrogram, penguj i perangkat
lunak, dan pihak-pihak lainnya t ermasuk pemakai dan pelanggan.
Proyek (proj ect )
Pekerjaan pengembangan perangkat lunaknya sendiri, yang dikelola
sesuai prinsip-prinsip manaj emen proyek.
Produk (product )
Kode sumber (source code), execut able programs, model-model, dan
dokumen-dokumen yang dihasilkan sebagai produk selama
pelaksanaan pengembangan.
Proses (process)
Kumpulan akt ivit as yang digunakan unt uk menghasilkan perangkat
lunak. Setiap akt ivitas dilaksanakan dengan menggunakan
pendekatan at au met ode teknis tert ent u.
Alat bantu
Kumpulan perangkat bantu atau kakas otomat is dan semi-otomat is
yang akan digunakan untuk mendukung aktivit as-akt ivit as dari proses.

Hubungan kelima elemen yang t erkait dengan proses pengembangan di atas


ditunj ukkan oleh Gambar 2.2 berikut .

BAB 2: MODEL PROSES PERANGKAT LUNAK

21

Proses
template

Orang

Proyek
partisipan

otomasi

Alat Bantu

hasil

Produk

Gambar 2.2 Hubungan Ant ar Elemen Proses Pengembangan


(Sumber: Jacobson, Booch, and Rumbaugh [JAC99])

2.2 Aktivitas Pengembangan Perangkat Lunak


Secara praktis sesuai kronologis pengerj aannya, akt ivitas pengembangan
perangkat lunak meliputi:

persiapan pengembangan

perancangan sistem

perancangan perangkat lunak

penguj ian perangkat lunak

penguj ian sist em

analisis kebut uhan sistem

analisis kebut uhan perangkat lunak

implementasi perangkat lunak (coding)

integrasi perangkat lunak

penyerahan kepada pemakai (user accept ance)

Semua akt ivitas yang di atas akan selalu berulang seiring dengan munculnya
kebutuhan unt uk membuat perangkat lunak yang lain j ika:

perangkat lunak yang ada sudah t idak dapat memenuhi kebut uhan
lagi akibat adanya perubahan lingkungan dan teknologi.

22

BAGIAN I: KONSEP DASAR

munculnya masalah-masalah atau proses bisnis baru yang sebelumnya


tidak ada.
adanya peluang bisnis baru.
berubahnya keinginan dan pengharapan pemakai.

2.2.1 Persiapan Pengembangan


Akt ivitas awal dari proses pengembangan perangkat lunak yang bert uj uan
unt uk menetapkan baseline dari pengerj aan pengembangan:
1.

Pendefinisian model proses pengembangan perangkat lunak yang


akan digunakan (beberapa model proses pengembangan akan dibahas
secara lebih rinci di bagian 2.3).

2.

Penentuan standar yang akan dij adikan acuan, misalnya standar dari
IEEE (lihat di htt p:/ / standards.ieee.org) atau MIL-STD-498 (lihat di
ht tp:/ / www.sepo.spawar.navy.mil/ sepo/ docs.html), sert a alat bantu
dan perangkat implementasi yang akan digunakan.

3.

Pembuatan rencana pengembangan (lihat IEEE St d 1058-1998


St andard f or Soft ware Proj ect Management Plans (SPMP) at au
Soft ware Development Plans (SDP) dari MIL-STD-498). Cont oh
sederhana dari rencana pengembangan ini dapat dilihat pada
Lampiran C.

4.

Penet apan produk-produk yang akan diserahkan kepada pemakai.

2.2.2 Analisis Kebutuhan Sistem


Akt ivitas unt uk mempelajari dan menent ukan kebut uhan sist em yang menjadi
lingkungan dimana perangkat lunak akan beroperasi, meliput i:

kebut uhan lingkungan sist em, mencakup kebut uhan perangkat keras,
perangkat lunak, dan komunikasi data.

kebut uhan bisnis fungsional.

kebut uhan antarmuka sist em.

kebut uhan informasi.

kebut uhan lain, sepert i unj uk kerj a, keselamat an, keamanan, dan
sebagainya.

Pembahasan rinci untuk aktivitas analisis kebutuhan sist em akan disampaikan


pada Bab 3.

BAB 2: MODEL PROSES PERANGKAT LUNAK

23

2.2.3 Perancangan Sistem


Akt ivit as untuk merancang st rukt ur dan ket erkaitan antar komponenkomponen sist em sesuai krit eria yang sudah dit etapkan, t ermasuk antarmuka
dengan lingkungan operasionalnya. Obj ek perancangan sist em pada dasarnya
meliputi:

prosedur (berkait an dengan bagaimana sist em nant i akan digunakan).


antarmuka, misalnya formulir isian dan dokumen out put, at au modulmodul penghubung.
arsitekt ur perangkat keras dan perangkat lunak sist em.
dat a dan informasi.

Pembahasan rinci untuk akt ivitas perancangan sistem akan disampaikan pada
Bab 3.

2.2.4 Analisis Kebutuhan Perangkat Lunak


Akt ivit as unt uk mendefinisikan kebutuhan perangkat lunak, yait u kondisi atau
kemampuan yang harus dimiliki oleh perangkat lunak unt uk memenuhi apa
yang disyarat kan atau diinginkan pemakai.
Pembahasan rinci unt uk aktivit as analisis kebut uhan perangkat lunak akan
disampaikan pada Bab 4, 5, dan 6.

2.2.5 Perancangan Perangkat Lunak


Akt ivit as unt uk menent ukan bagaimana perangkat lunak memenuhi kebut uhan
yang sudah didefinisikan. Cakup perancangan meliputi perancangan data,
arsit ektur perangkat lunak, antarmuka, dan algorit ma.
Pembahasan rinci unt uk aktivitas perancangan perangkat
disampaikan pada Bab 7, 8, dan 9.

lunak akan

2.2.6 Implementasi Perangkat Lunak (Coding)


Akt ivit as unt uk mewuj udkan perangkat lunak melalui proses transformasi
semua model hasil perancangan menj adi program komput er dan data, dengan
menggunakan perangkat implementasi tert entu.
Pembahasan rinci unt uk aktivitas implementasi
disampaikan pada Bab 10.

perangkat

lunak akan

24

BAGIAN I: KONSEP DASAR

2.2.7 Pengujian Perangkat Lunak


Akt ivitas unt uk memeriksa perangkat lunak yang dihasilkan apakah sudah
memenuhi kebut uhan yang sudah didefinisikan atau belum. Cakupan penguj ian
meliput i penguj ian unit atau modul program, integrasi modul, dan validasi.
Pembahasan rinci untuk aktivitas implementasi
disampaikan pada Bab 11.

perangkat

lunak akan

2.2.8 Integrasi Perangkat Lunak


Akt ivitas unt uk mengint egrasikan perangkat lunak yang sudah selesai diuj i
dengan perangkat keras dan bagian-bagian sist em lainnya menj adi suatu
kesat uan. Pelaksanaan integrasi perangkat lunak dilaksanakan apabila semua
lingkungan operasi dan sarana yang dibut uhkannya sudah siap.
Secara umum, pelaksanaan integrasi perangkat lunak meliput i:
1.

Pembuatan rencana integrasi dan dokument asinya.

2.

Inst alasi perangkat keras dan perangkat lunak pendukung yang


dibutuhkan oleh perangkat lunak.

3.

Penguj ian apakah perangkat keras yang sudah diinstalasi dan


perangkat lunak pendukungnya sudah bekerj a dengan benar.

4.

Inst alasi perangkat lunak.

5.

Penguj ian dan evaluasi hasil int egrasi.

2.2.9 Pengujian Sistem


Akt ivitas unt uk menguj i perangkat lunak di lingkungan sebenarnya dengan
menggunakan data sebenarnya, dan melibat kan komponen sist em lainnya,
seperti perangkat keras, perangkat komunikasi data, pemakai, dan prosedurprosedur seperti prosedur manual, prosedur audit , dan prosedur keamanan.
Tuj uan yang diharapkan tidak lain adalah untuk meyakinkan bahwa perangkat
lunak yang dibuat dapat berintegrasi kedalam sistem dan beroperasi sesuai
kebut uhan.
Pelaksanaan penguj ian sistem secara umum meliputi:
1.

Pembuatan dokumen rencana penguj ian sist em.

2.

Penyusunan pet unj uk operasi.

3.

Konversi dan penyiapan data yang sebenarnya.

BAB 2: MODEL PROSES PERANGKAT LUNAK

25

4.

Pelaksanaan penguj ian oleh pemakai atau perwakilan pemakai yang


benar-benar mengetahui kebut uhannya.

5.

Evaluasi hasil penguj ian.

2.2.10 Penyerahan Kepada Pemakai (User Acceptance)


Apabila pemakai dapat menerima seluruh hasil penguj ian, perangkat lunak
dapat segera diseraht erimakan. Sebagai kelengkapan, diserahkan j uga
dokumen-dokumen pendukungnya sepert i:

spesifikasi produk perangkat lunak

manual masukan/ keluaran perangkat lunak

manual pemakaian perangkat lunak

manual pengoperasian komputer

2.3 Model Proses Pengembangan Perangkat Lunak


Model proses pengembangan perangkat lunak adalah suat u cara atau st rategi
pengembangan yang memadukan met ode, t eknik, dan alat bantu sedemikian
rupa sehingga produk perangkat lunak dapat diwuj udkan. Model proses ini ada
karena beragamnya sifat proyek dan aplikasi, metode dan alat yang digunakan,
serta pengendalian dan hasil yang diinginkan.
Sampai saat ini sudah banyak model proses pengembangan yang dikenal.
Berikut adalah penj elasan unt uk beberapa model proses pengembangan
perangkat lunak yang sering digunakan.

2.3.1 Waterfall Model


Model proses wat erf all (atau disebut j uga classic life cycle) adalah model
proses pengembangan perangkat
lunak yang pelaksanaan proses
pengembangannya dilakukan secara berurutan. Hal ini berarti bahwa aktivit as
pengembangan berikut nya baru dapat dilaksanakan j ika akt ivitas sebelumnya
sudah diselesaikan lebih dahulu.
Set iap tahapan akt ivitas pada model proses waterf all ini akan menghasilkan
keluaran yang diperlukan sebagai bahan masukan untuk melanj utkan ke tahap
berikut nya, at au sebagai umpan balik unt uk memperbaiki kekurangan atau
kesalahan yang mungkin ada di tahap sebelumnya. Gambar 2.3 berikut
mengilustrasikan model proses linear sequent ial yang disampaikan unt uk
pertama kalinya oleh Winst on Royce pada tahun 1970.

26

BAGIAN I: KONSEP DASAR

Analisis
Kebutuhan
Perancangan
Pengkodean
Pengujian
Pengoperasian

Gambar 2.3 Model Proses Wat erfall


(Sumber: Davis [DAV93])
Cakupan aktivitas yang ada pada model proses wat erf all meliput i:
1.

Analisis kebut uhan


Mempelaj ari dan memahami masalah yang akan dibuat perangkat
lunaknya, menetapkan ranah informasi, fungsi, perilaku, unj uk kerja
dan antarmuka perangkat lunak untuk didefinisikan sebagai
kebut uhan perangkat lunak.

2.

Perancangan
Transformasi set iap spesifikasi kebut uhan menj adi modul-modul
perancangan yang lebih rinci sehingga menghasilkan model solusi
dalam bent uk rancangan st rukt ur data, arsit ekt ur perangkat lunak,
antar muka, dan prosedur-prosedur atau algorit ma.

3.

Pengkodean
Menerj emahkan model perancangan ke dalam bentuk yang dapat
dimengert i oleh mesin (komputer) dengan menggunakan perangkat
implementasi tert entu.

4.

Penguj ian
Memeriksa kebenaran logika int ernal dan fungsi perangkat lunak
unt uk menemukan kesalahan-kesalahan, dan memast ikan bahwa
perangkat lunak yang dihasilkan sesuai dengan kebutuhan yang sudah
didefinisikan sebelumnya.

5.

Pengoperasian
Penggunaan perangkat lunak oleh pemakai di lingkungan sebenarnya.
Unt uk menj aga supaya perangkat lunak yang dioperasikan ini tet ap
berj alan sebagaimana mest inya, dilakukan proses pemeliharaan.

Versi lain dari model proses wat erfall adalah model proses linear sequent ial
(lihat Gambar 2.4). Pada model proses ini, setiap akt ivitas dilaksanakan secara
linear, tanpa umpan balik unt uk memperbaiki t ahap sebelumnya.

BAB 2: MODEL PROSES PERANGKAT LUNAK

27

R ekayasa Sistem /
Inform asi

Analisis

P erancangan

Pengkodean

Pengujian

Gambar 2.4 Model Proses Linear Sequent ial


(Sumber: Pressman [PRE01])
Model proses wat erfall atau linear sequent ial pada umumnya dipilih j ika
semua kebut uhan sudah j elas dan dapat didefinisikan secara eksplisit di awal
proses pengembangan.

2.3.2 Prototyping Model


Pendekatan model prot ot yping dipilih j ika kebutuhan belum dapat
didefinisikan secara j elas dan t egas. Pemakai hanya memberikan gambaran
umum dari spesifikasi dan kegunaan perangkat lunak tanpa merinci seperti apa
masukan, poses, dan keluarannya.
Model proses prot ot yping dilaksanakan secara berulang dengan diawali oleh
akt ivitas pengumpulan kebutuhan sist em dan berakhir j ika produk perangkat
lunak yang dihasilkan sudah sesuai dengan yang diharapkan oleh pemakai
seperti ditunj ukkan oleh Gambar 2.5.
Cakupan aktivitas model prot ot yping secara lengkap meliput i akt ivitas:
1.

Pengumpulan kebut uhan dan perbaikan


Pengembang bert emu dengan pemakai (pelanggan) unt uk
menent ukan obj ektif perangkat lunak secara keseluruhan dan
mengidentifikasi kebutuhan-kebutuhan yang sudah diketahui.

2.

Perancangan cepat
Melakukan perancangan secara cepat dengan fokus pada hal-hal yang
akan langsung t erlihat oleh pemakai, seperti antarmuka pemakai dan
fungsi-fungsi dasar.

3.

Membangun protot ype


Model perancangan yang dihasilkan selanj ut nya digunakan unt uk
membuat prot ot ype pertama, yang mungkin berbentuk:

Int eract ions prot ot ype


Prot ot ype perangkat lunak yang memungkinkan pemakai unt uk
memahami bagaimana berint eraksi dengan sist em perangkat
lunak.

28

BAGIAN I: KONSEP DASAR

Subset funct ion prot ot ype


Prot ot ype perangkat lunak yang sudah dapat digunakan tetapi
baru mengimplementasikan sebagian dari fungsi-fungsi yang
diinginkan.
Exist ing program
Program sebenarnya yang mengimplementasikan sebagian besar
atau seluruh fungsionalit as yang dibutuhkan, tetapi masih ada
hal-hal utama lainnya yang harus disempurnakan pada
pengembangan berikut nya.

4.

Evaluasi prot ot ype


Menguj i coba dan mengevaluasi prot ot ype bersama-sama dengan
pemakai untuk mendapatkan umpan balik yang dapat membantu
pengembang memperbaiki prot ot ype yang sudah dibuat, at au
membangun protot ype yang baru.

5.

Perbaikan prot ot ype


Melakukan penambahan dan perbaikan-perbaikan terhadap prot ot ype
berdasarkan hasil evaluasi sampai diperoleh produk yang diinginkan.

Pengumpulan
Kebutuhan

Perbaikan
Prototype

Evaluasi
Prototype

Perancangan
Cepat

Bangun
Prototype

Gambar 2.5 Model Proses Prot ot yping

2.3.3 Incremental Model


Model proses evolusioner yang mengkombinasikan model linear sequent ial dan
pengulangan dari model prot ot yping. Setiap sat u kali pelaksanaan model
linear sequent ial akan dihasilkan suat u penambahan (deliverable increment )

BAB 2: MODEL PROSES PERANGKAT LUNAK

29

bagi perangkat lunak. Hasil penambahan yang pert ama biasanya merupakan
produk inti yang mewakili kebut uhan dasar dari sistem. Produk int i inilah yang
nant inya akan ditambah t erus-menerus sampai didapat produk yang lengkap
dan memenuhi kebut uhan pemakai (lihat Gambar 2.6).
penambahan
pertama

Analisis

penambahan
kedua

Perancangan

Analisis

Implementasi

Perancangan

Pengujian

Implementasi

hasil penambahan
pertama

Pengujian

hasil penambahan
kedua

.
.
.
penambahan
ke-n

Analisis

Perancangan

Implementasi

Pengujian

hasil akhir /
produk lengkap

Gambar 2.6 Model Proses Increment al


(Sumber: Pressman [PRE01])
Sebagai gambaran, misalkan dikembangkan perangkat lunak t ext edit or. Hasil
penambahan pertama mungkin berupa t ext edit or dengan fasilitas unt uk
membent uk, membuka, menyunt ing, dan menyimpan dokumen t eks. Pada
penambahan kedua, disert akan fasilitas unt uk mengat ur halaman dan
mencet ak. Dan pada penambahan berikutnya didapat produk akhir t ext edit or
yang sudah ditambahi dengan fasilitas pengat uran font , pencarian dan
penggant ian kata, sert a fasilitas bant uan (help).

2.3.4 Spiral Model


Model proses perangkat lunak evolusioner yang mengadopsi pengulangan model
prot ot yping dan pengendalian model linear sequent ial dengan tambahan
elemen analisis resiko pada proses pengembangannya. Representasi model ini
berbentuk spiral (Gambar 2.7), dimana set iap pengulangan dinyatakan dengan
suatu sirkuit yang melingkari 4 aktivitas utama:
1.

Perencanaan
Mendefinisikan tuj uan, kendala, sumber daya, wakt u, dan informasi
lain yang berhubungan dengan proyek.

2.

Analsis resiko
Mengenali, menganalisis dan menilai resiko teknis dan manaj emen.

3.

Rekayasa
Membangun satu atau beberapa produk yang merepresent asikan
aplikasi.

30

BAGIAN I: KONSEP DASAR

4.

Evaluasi pemakai
Mendapat kan umpan balik dari pemakai berdasarkan hasil evaluasi
produk yang direkayasa.
PERENCANAAN

EVALUASI PEMAKAI

ANALISIS RESIKO

REKAYASA

Gambar 2.7 Model Proses Spiral

2.3.5 Rational Unified Process (RUP)


RUP adalah proses pengembangan perangkat lunak berbasis UML (Unified
Modeling Language) yang mempunyai karakteristik:
1.

Berulang (it erat ive)


Tahap pengembangan unt uk set iap produk yang diserahkan (release)
dilaksanakan secara berulang.

2.

Archit ect ure cent ric


Menggunakan arsit ekt ur sistem sebagai art ifak ut ama unt uk
konsept ualisasi, konstruksi, pengelolaan, dan penyusunan sistem
selama pengembangan.

3.

Use case-driven
Menggunakan use case sebagai art ifak utama unt uk menetapkan
perilaku sist em yang diinginkan dan unt uk mengkomunikasikan
perilaku sist em tersebut kepada para st akeholder sist em.

4.

Risk-driven
Menghilangkan atau mengurangi
menghambat kesuksesan proyek.

resiko-resiko

yang

dapat

BAB 2: MODEL PROSES PERANGKAT LUNAK

31

Sasaran RUP adalah menghasilkan perangkat lunak yang berkualit as tinggi,


sesuai kebut uhan pemakai, dengan j adwal dan biaya sesuai dengan yang
direncanakan

Gambar 2.8 Model Proses Pengembangan dengan RUP


(Sumber: www.rational.com)
Proses pengembangan pada RUP dinyatakan dalam dua dimensi, atau dua
sumbu (lihat Gambar 2.8).

sumbu horizontal (sumbu x) merepresent asi wakt u dan menunj ukkan


aspek dinamis dari proses, yaitu siklus, tahap, iterasi, dan milest one.
sumbu vert ikal (sumbu y) merepresentasikan aspek st at is dari proses,
yait u akt ivitas, art ifak, pelaksana kerj a (worker) dan aliran kerja
(workflow).

2.3.5.1 Tahap RUP


Berdasarkan Gambar 2.8, t ahap (phases) pelaksanaan pengembangan pada RUP
meliputi:
1.

Permulaan (incept ion)


Tahap incept ion fokus pada penent uan manfaat perangkat lunak yang
harus dihasilkan, penetapan proses-proses bisnis (business case), dan
perencanaan proyek.

32

BAGIAN I: KONSEP DASAR

2.

Pemerincian (elaborat ion)


Tahap unt uk menentukan use case (set of act ivit ies) dari perangkat
lunak berikut rancangan arsitekt urnya.

3.

Konst ruksi (const ruct ion)


Membangun produk perangkat lunak secara lengkap yang siap
diserahkan kepada pemakai.

4.

Transisi (t ransit ion)


Menyerahkan perangkat lunak kepada pemakai, menguj inya di
tempat pemakai, dan memperbaiki masalah-masalah yang muncul
saat dan set elah penguj ian.

2.3.5.2 Aliran Kerja RUP


Ada dua j enis aliran kerj a (workf low) pada RUP, yaitu aliran kerja utama dan
aliran kerj a pendukung.
Aliran Kerja Utama
1.
2.

3.

4.

5.
6.

Pemodelan bisnis (business modeling)


Mendeskripsikan st rukt ur dan proses-proses bisnis organisasi.
Kebutuhan (requirement s)
Mendefinisikan kebutuhan perangkat lunak dengan menggunakan met ode
use case.
Analisis dan perancangan (analysis and design)
Mendeskripsikan berbagai arsitekt ur perangkat lunak dari berbagai sudut
pandang.
Implement asi (implement at ion)
Menulis kode-kode program, menguj i, dan mengint egrasikan unit-unit
programnya.
Penguj ian (t est ing)
Mendeskripsikan kasus uj i, prosedur, dan alat ukur penguj ian.
Deployment
Menangani konfigurasi sist em yang akan diserahkan.

Aliran Kerja Pendukung


1.

2.

3.

Manaj emen konfigurasi dan perubahan (conf igurat ion and change
management )
Mengendalikan perubahan dan memelihara art ifak-artifak proyek.
Manaj emen proyek (proj ect management )
Mendeskripsikan berbagai strat egi pekerj aan dengan proses yang
berulang.
Lingkungan (environment )
Menangani infrastruktur yang dibut uhkan unt uk mengembangkan sist em.

BAB 2: MODEL PROSES PERANGKAT LUNAK

33

2.4 Metode Pengembangan Perangkat Lunak


Yang dimaksud dengan metode pengembangan perangkat lunak disini adalah
pendekatan, sudut pandang, atau kumpulan at uran yang harus diikuti unt uk
menyelesaikan t ahap-tahap pekerj aan saat melaksanakan pengembangan
perangkat lunak. Ada beberapa pendekatan at au met ode yang sudah dikenal,
dan berikut adalah penj elasan untuk met ode-metode yang sering digunakan.

2.4.1 Konvensional atau Tradisional


Sudut pandang pengembangan pada met ode ini dituj ukan pada sist em fisik
(prosedur kerj a) yang ada dalam suatu organisasi. Tahap pengembangan
biasanya diawali dengan mengamat i dokumen apa yang menj adi media data
atau informasi, bagaimana dokumen t ersebut terbent uk, bagaimana dokumen
t ersebut mengalir dari satu bagian ke bagian yang lain, proses apa yang t erj adi
pada dokumen tersebut, dan set erusnya.
Hasil set iap t ahap pengembangan dimodelkan dengan menggunakan alat bantu
yang disebut bagan alir (flowchart ) yang menggunakan simbol-simbol tert entu
yang sudah dibakukan oleh ANSI (American National Standard Inst itut e).
Pemodelan yang dibuat pada umumnya adalah:
1.

Peta aliran kerj a (f lowmap)


Menggambarkan prosedur kerja secara fisik, baik yang masih manual
atau yang sudah menggunakan komput er, dilihat berdasarkan aliran
dokumen yang digunakan.

2.

Syst em Flowchart
Menggambarkan kerangka proses program dilihat dari masukan,
proses dan keluarannya.

3.

Program Flowchart
Menggambarkan urut-urut an logika proses dari program.

Cont oh hasil pengembangan perangkat lunak dengan met ode konvensional


dapat dilihat pada Lampiran B.

2.4.2 Berorientasi Aliran Data atau Fungsi


Sudut pandang pengembangan dengan metode ini adalah aspek fungsional dan
perilaku laku sist em. Pengembang harus mengetahui fungsi-fungsi at au prosesproses apa saj a yang ada dalam sist em, data apa yang menj adi masukannya,
dimana data tersebut disimpan, transformasi apa yang akan dilakukan
t erhadap dat a t ersebut, dan apa yang menj adi hasil t ransformasinya. Selain
it u, pengembang harus mengetahui keadaan, perubahan, kondisi, dan aksi dari
sist em.

34

BAGIAN I: KONSEP DASAR

Salah sat u t eknik yang paling populer unt uk met ode ini adalah Teknik
Terst rukt ur (St ruct ured Technique) yang meliputi analisis, perancangan, dan
pemrograman. Pada t eknik ini, hasil analisis dan perancangan dimodelkan
dengan menggunakan alat bant u pemodelan sepert i:
1.

Diagram Aliran Data (Data Flow Diagram atau DFD)


Digunakan untuk menggambarkan aliran data dalam sist em, sumber
dan t uj uan dat a, proses yang mengolah data tersebut , dan t empat
penyimpanan datanya.

2.

Kamus Data (Data Dict ionary)


Digunakan untuk mendeskripsikan st rukt ur dari data atau informasi
yang mengalir (ada) dalam sistem.

3.

Spesifikasi Proses (Process Specificat ion atau P-Spec)


Digunakan unt uk menggambarkan deskripsi dan spesifikasi dari setiap
proses yang ada pada sistem, biasanya untuk proses-proses at omik,
dengan menggunakan not asi yang disebut St ruct ured English.

4.

Diagram Transisi Keadaan (Stat e Transit ion Diagram atau STD)


Digunakan untuk menggambarkan perilaku sist em, dan biasanya
unt uk sist em wakt u nyat a (real t ime).

5.

Diagram E-R
Digunakan untuk menggambarkan hubungan (relat ionship) antara
ent itas-entitas dilihat dari aspek datanya (at au hubungan antar
tempat penyimpanan).

6.

Bagan Terst rukt ur (St ruct ure Chart )


Digunakan unt uk menggambarkan st rukt ur atau arsit ekt ur program.

7.

Pseudo-code
Digunakan unt uk menuliskan algorit ma set iap modul program.

Penj elasan rinci untuk met ode pengembangan berorientasi aliran dat a ini akan
disampaikan pada Bab 5 dan 8.

2.4.3 Berorientasi Data


Sudut pandang pengembangan pada met ode ini adalah struktur data dari
dokumen masukan/ keluaran yang digunakan dalam sist em. Tahap pelaksanaan
pengembangannya pada umumnya mengikuti urut an sebagai berikut :
1.

Mengident ifikasi entit as-ent it as atau it em-it em yang menj adi obj ek
informasi kunci berikut operasi-operasinya.

2.

Menyatakan struktur informasi (dari dokumen) secara hirarki dengan


menggunakan konst ruksi sequence, select ion dan repet it ion.

3.

Memetakan hirarki struktur informasi menj adi st ruktur program.

BAB 2: MODEL PROSES PERANGKAT LUNAK

35

Beberapa t eknik pengembangan perangkat lunak berorient asi st rukt ur data ini
diantaranya adalah:

Dat a St ruct ured System Development (DSSD)


Diperkenalkan pertama kali oleh J.D. Warnier (1974) dan kemudian
oleh Ken Orr (1977) sehingga sering disebut j uga t eknik Warnier-Orr.
Teknik ini menggunakan perangkat ent it y diagram, assembly line
diagram dan Warnier-Orr diagram unt uk memodelkan hasil analisis
dan perancangannya.

Jackson System Development (JSD)


Dikembangkan oleh M.A. Jackson (1975) dengan menggunakan
perangkat pemodelan yang disebut st ruct ure diagram dan syst em
specif icat ion diagram.

2.4.4 Berorientasi Objek


Berbeda dengan pendekatan-pendekatan sebelumnya, metode berorient asi
obj ek memandang perangkat lunak yang akan dikembangkan sebagai suatu
kumpulan obj ek yang berkorespondensi dengan obj ek-obj ek dunia nyata. Pada
metode ini, informasi dan proses yang dipunyai oleh suatu obj ek
dienkapsulasi (dibungkus) dalam satu kesat uan. Gambar 2.9 berikut
menunj ukkan cara pandang met ode berorient asi obj ek dibandingkan dengan
metode berorientasi fungsi.
Sistem
Akademik

Dekomposisi berdasarkan objek atau konsep


Dosen

Jadwal

Mahasiswa

Dekomposisi berdasarkan fungsi atau proses

Kuliah

Kontrak
Kuliah

Metodologi Berorientasi Objek

Konteks

Pengambilan
Kuliah

Penjadwalan

Penilaian

Metodologi Berorientasi Fungsi

Gambar 2.9 Sudut Pandang Met ode Berorient asi Obj ek vs Fungsi
Beberapa t eknik pengembangan perangkat lunak yang berorientasi obj ek ini
diantaranya adalah:

Obj ect Oriented Analysis (OOA) dan Obj ect Oriented Design (OOD)
dari Pet er Coad dan Edward Yourdon (1990).

36

BAGIAN I: KONSEP DASAR

Obj ect Modeling Technique (OMT) dari James Rumbaugh, Michael


Blaha, William Premerlan, Frederick Eddy dan William Lorensen
(1991).
Obj ect Oriented Soft ware Engineering (OOSE) dari Ivar Jacobson
(1992).
Met ode Booch dari Grady Booch (1994).
Synt ropy dari St eve Cook dan John Daniels (1994).

Pembahasan rinci untuk met ode pengembangan obj ek dij elaskan pada Bab 6
dan 9.

BAB 2: MODEL PROSES PERANGKAT LUNAK

37

Rangkuman
1.

Pengembangan perangkat lunak adalah salah satu proses dari berbagai


proses yang ada dalam rekayasa perangkat lunak. Pada proses ini,
kebut uhan pemakai ditransformasi menj adi perangkat lunak.

2.

Walaupun pelaksanaan proses pengembangan mungkin mempunyai ragam


aktivitas yang berlainan, tet api pada umumnya terdiri dari: penetapan
baseline, analisis dan perancangan sistem, analisis kebut uhan dan
perancangan perangkat lunak, penulisan program, penguj ian, inst alasi dan
penguj ian sist em, dan penyerahan kepada pemakai.

3.

Model proses pengembangan adalah cara at au st rategi bagaimana


mengembangkan perangkat lunak berdasarkan model proses, metode
pengembangan, t eknik, dan alat bantu tert ent u sehingga produk
perangkat lunak dapat diwuj udkan. Penent uan model proses mana yang
digunakan saat pengembangan, t ergant ung sepenuhnya kepada sifat dan
ukuran proyek, area aplikasi, atau kompleksit as masalah.

4.

Met ode pengembangan adalah metode t eknis unt uk menyelesaikan setiap


aktivitas dari pengembangan perangkat lunak yang mempunyai
pendekatan, sudut pandang, dan kumpulan aturan t ertent u. Jika
diklasifikasi sesuai pendekatannya, dikenal empat met ode pengembangan,
yait u metode konvensional, berorientasi fungsi, data, dan obj ek.

Daftar Pustaka
[DAV93] Davis, Alan M., Soft ware Requirements: Obj ects, Functions and
Stat es , Prentice-Hall Int ernat ional Edit ions, Englewood Cliffs, New
Jersey, 1993.
[DOD94] US Department of Defense, MIL-STD-498 Software Development and
Document ation, 1994.
[IEE93]

The Inst itute of Elect rical and Electronics Engineers, IEEE Std
610.12-1993 Standard Glossary of SW Engineering Terminology ,
1993.

[IEE98]

The Inst itute of Elect rical and Electronics Engineers; Electronic


Industries Association (EIA), IEEE/ EIA 12207.0 Standard for
Information Technology - Soft ware Life Cycle Processes , 1998.

[JAC99] Jacobson, Ivar; Booch, Grady; and Rumbaugh, James The Unified
Soft ware Development Process , Addison Wesley, Reading,
Massachusett s, 1999.

38

BAGIAN I: KONSEP DASAR

[LAR98] Larman, Craig, Applying UML and Pat erns An Introduct ion to
Obj ect-Orient ed Analysis and Design , Prent ice-Hall PTR, Upper
Saddle River, New Jersey, 1998.
[PRE01] Pressman, Roger S., Soft ware Engineering: A Practioner s
Approach , Fift h Edit ion, MacGraw-Hill Int ernat ional Editions, 2001.
[RAT99] Rat ional Software, The Rat ional Unified Process , November, 1999.

Anda mungkin juga menyukai