Ketika kita bekerja dengan komputer kita membutuhkan serangkaian
tahapan dan cara-cara tertentu agar dapat menghasilkan sesuatu yang
menjadi harapan kita. Demikian juga dalam rekayasa perangkat lunak,
diperlukan tahapan-tahapan kerja yang harus dilalui. Rekayasa perangkat
lunak yang sukses tidak hanya membutuhkan kemampuan komputasi seperti
algoritma, pemrograman, dan basis data yang kuat, namun juga perlu
penentuan tujuan yang baik, identifikasi cara penyelesaian, metode
pengembangan, urutan aktifitas, identifikasi kebutuhan sumberdaya, dan
faktor-faktor lain. Hal-hal seperti ini terkait dengan apa yang disebut
dengan metode rekayasa perangkat lunak.
Pada rekayasa perangkat lunak, banyak model yang telah dikembangkan
untuk membantu proses pengembangan perangkat lunak. Model-model ini
pada umumnya mengacu pada model proses pengembangan sistem yang disebut
System Development Life Cycle (SDLC).
Setiap model yang dikembangkan mempunyai karakteristik
sendirisendiri. Namun secara umum ada persamaan dari model-model ini,
yaitu:
- Kebutuhan terhadap definisi masalah yang jelas. Input
utama dari setiap model pengembangan perangkat lunak adalah
pendefinisian masalah yang jelas. Semakin jelas akan semakin baik karena
akan memudahkan dalam penyelesaian masalah. Oleh karena itu pemahaman
masalah seperti dijelaskan pada pembahasan sebelumnya, merupakan bagian
penting dari model pengembangan perangkat lunak.
- Tahapan-tahapan pengembangan yang teratur. Meskipun
model-model pengembangan perangkat lunak memiliki pola yang
berbeda-beda, biasanya model-model tersebut mengikuti pola umum analysis
– design – coding – testing - maintenance.
- Stakeholder berperan sangat penting dalam keseluruhan tahapan pengembangan.
Stakeholder dalam rekayasa perangkat lunak dapat berupa pengguna,
pemilik, pengembang, pemrogram dan orang-orang yang terlibat dalam
rekayasa perangkat lunak tersebut.
- Dokumentasi merupakan bagian penting dari pengembangan perangkat lunak.
Masing-masing tahapan dalam model biasanya menghasilkan sejumlah
tulisan, diagram, gambar atau bentuk-bentuk lain yang harus
didokumentasi dan merupakan bagian tak terpisahkan dari perangkat lunak
yang dihasilkan.
- Keluaran dari proses pengembangan perangkat lunak harus bernilai ekonomis.
Nilai dari sebuah perangkat lunak sebenarnya agak susah dirupiah- kan.
Namun efek dari penggunaan perangkat lunak yang telah dikembangkan
haruslah memberi nilai tambah bagi organisasi. Hal ini dapat berupa
penurunan biaya operasi, efisiensi penggunaan sumberdaya, peningkatan
keuntungan organisasi, peningkatan “image” organisasi dan lain-lain.
Ada banyak model pengembangan perangkat lunak, antara lain The
Waterfall Model, Joint Application Development (JAD), Information
Engineering (IE), Rapid Application Development (RAD) termasuk di
dalamnya Prototyping, Unified Process (UP), Structural Analysis and
Design (SAD) dan Framework for the Application of System thinking
(FAST). Pada kesempatan kali ini kita akan dibahas tiga model
pengembangan yaitu The Waterfall Model, Prototyping, dan Unified
Processs (UP).
MODEL PENGEMBANGNA PERANGKAT LUNAK
Seperti yang telah di atas kita akan membahas beberapa model
pengembangan perangkat lunak. Untuk model - model yang lain anda kita
akan membahasnya di lain kesempatan atau anda dapat mencari literatur
sendiri di internet yang saya rasa cukup banyak materi yang menyediakan
tersebut.
Model siklus hidup (life cycle model) adalah model utama dan
dasar dari banyak model. Salah satu model yang cukup dikenal dalam dunia
rekayasa perangkat lunak adalah The Waterfall Model. Ada 5 tahapan
utama dalam The Waterfall Model seperti terlihat pada Gambar di bawah
ini. Disebut waterfall (berarti air terjun) karena memang diagram
tahapan prosesnya mirip dengan air terjun yang bertingkat.
Tahapan-tahapan dalam The Waterfall Model secara ringkas adalah sebagai berikut:
- Tahap investigasi dilakukan untuk menentukan apakah terjadi
suatu masalah atau adakah peluang suatu sistem informasi dikembangkan.
Pada tahapan ini studi kelayakan perlu dilakukan untuk menentukan apakah
sistem informasi yang akan dikembangkan merupakan solusi yang layak
- Tahap analisis bertujuan untuk mencari kebutuhan pengguna dan
organisasi serta menganalisa kondisi yang ada (sebelum diterapkan sistem
informasi yang baru).
- Tahap disain bertujuan menentukan spesifikasi detil dari
komponen komponen sistem informasi (manusia, hardware, software, network
dan data) dan produk-produk informasi yang sesuai dengan hasil tahap
analisis.
- Tahap implementasi merupakan tahapan untuk mendapatkan atau
mengembangkan hardware dan software (pengkodean program), melakukan
pengujian, pelatihan dan perpindahan ke sistem baru.
- Tahapan perawatan (maintenance) dilakukan ketika sistem
informasi sudah dioperasikan. Pada tahapan ini dilakukan monitoring
proses, evaluasi dan perubahan (perbaikan) bila diperlukan.
Prototyping adalah salah satu pendekatan dalam
rekayasa perangkat lunak yang secara langsung mendemonstrasikan
bagaimana sebuah perangkat lunak atau komponen-komponen perangkat lunak
akan bekerja dalam lingkungannya sebelum tahapan konstruksi aktual
dilakukan (Howard, 1997). Prototyping model dapat diklasifikasikan
menjadi beberapa tipe seperti di tunjukkan sebagai gambar berikut ini.
- Reusable prototype :
Prototype yang akan ditransformasikan menjadi produk final.
- Throwaway prototype :
Prototype yang akan dibuang begitu selesai menjalankan maksudnya.
- Input/output prototype :
Prototype yang terbatas pada antar muka pengguna (user interface).
- Processing prototype :
Prototype yang meliputi perawatan file dasar dan proses-proses transaksi.
- System prototype :
Prototype yang berupa model lengkap dari perangkat lunak.
Tahap-tahap dalam prototyping boleh dikata merupakan tahap-tahap
yang dipercepat. Strategi utama dalam prototyping adalah kerjakan yang
mudah terlebih dahulu dan sampaikan hasil kepada pengguna sesegera
mungkin. Harris (2003) membagi prototyping dalam enam tahapan seperti
gambar berikut ini.
Tahapan-tahapan secara ringkas dapat dijelaskan sebagai berikut:
- Identifikasi kandidat prototyping. Kandidat dalam kasus ini
meliputi user interface (menu, dialog, input dan output), file-file
transaksi utama, dan fungsi-fungsi pemrosesan sederhana.
- Rancang bangun prototype dengan bantuan software seperti word
processor, spreadsheet, database, pengolah grafik, dan software CASE
(Computer-Aided System Engineering).
- Uji prototype untuk memastikan prototype dapat dengan mudah dijalankan untuk tujuan demonstrasi
- Siapkan prototype USD (User’s System Diagram) untuk mengidentifikasi bagian-bagian dari perangkat lunak yang di-prototype-kan.
- Evaluasi dengan pengguna untuk mengevaluasi prototype dan melakukan perubahan jika diperlukan.
- Transformasikan prototype menjadi perangkat lunak yang
beroperasi penuh dengan melakukan penghilangan kode-kode yang tidak
dibutuhkan, penambahan program-program yang memang dibutuhkan dan
perbaikan dan pengujian perangkat lunak secara berulang.
- Unified Process dan Unified Modeling Language
Unified Process (UP) atau kadang disebut sebagai Unified Software
Development Process (USDP) adalah kerangka proses pengembangan yang
bersifat use-case driven, berpusat pada arsitektur perangkat lunak,
interatif dan tumbuh-kembang (Alhir, 2005). Kerangka pengembangan ini
termasuk baru dalam metodologi pengembangan perangkat lunak. UP dapat
diaplikasikan pada berbagai skala proyek, mulai dari skala kecil sampai
dengan skala besar. Daur hidup UP secara umum akan tampak seperti pada
bagan di Gambar di bawah ini.
Bagan ini biasa disebut sebagai “hump chart”. Pada bagan ini
terlihat ada empat tahap pengembangan yaitu inception, elaboration,
construction dan transition. Selain itu tampak pula sejumlah aktivitas
(disciplines) yang harus dilakukan sepanjang pengembangan perangkat
lunak, yaitu, business modeling, requirements, analysis and design,
implementation, test. Tahap dan aktivitas tersebut akan dilakukan secara
iteratif (Ambler, 2005). Penjelasan singkat untuk empat tahapan dalam
UP adalah sebagai berikut:
- Inception. Tahapan ini merupakan tahapan
paling awal dimana aktivitas penilaian terhadap sebuah proyek perangkat
lunak dilakukan. Tujuannya adalah untuk mendapatkan kesepakatan dari
stakeholder sehubungan dengan tujuan dan dana proyek.
- Elaboration. Tujuan dari tahap ini adalah
untuk mendapatkan gambaran umum kebutuhan, persyaratan dan fungsi-fungsi
utama perangkat lunak. Hal ini penting untuk mengetahui secara lebih
baik resiko-resiko proyek, baik meliputi resiko arsitektur perangkat
lunak, perencanaan, maupun implementasi. Pada tahap ini telah dimulai
rancang bangun perangkat lunak secara iterative melalui
aktivitas-aktivitas seperti business modeling, requirements, analysis
dan design meskipun baru pada tahap awal.
- Construction. Tujuan dari tahapan ini adalah
membangun perangkat lunak sampai dengan saat perangkat lunak tersebut
siap digunakan. Titik berat tahapan ini adalah pada penentuan tingkat
prioritas kebutuhan / persyaratan, melengkapi spesifikasinya, analisis
lebih dalam, disain solusi yang memenuhi kebutuhan dan persyaratan,
pengkodean dan pengujian perangkat lunak. Jika dimungkinkan versi awal
dari perangkat lunak diuji cobakan untuk mendapatkan masukan dari
pengguna.
- Transition. Tahap ini difokuskan pada
bagaimana menyampaikan perangkat lunak yang sudah jadi pada pengguna.
Perangkat lunak akan secara resmi diuji oleh baik oleh penguji (tester)
yang kompeten maupun oleh pengguna. Beberapa aktivitas seperti
pemindahan pusat data dan pelatihan pengguna dan staf pendukung harus
dilakukan pada tahap ini.
Dalam pengembangan perangkat lunak dengan menggunakan UP, maka
tidak lepas dari penggunaan notasi-notasi yang biasa disebut sebagai UML
(Unified Modeling Language). Meskipun UP mensyaratkan penggunaan UML,
namun UML sendiri dapat digunakan pada berbagai metodologi yang lain
bahkan dapat digunakan pada bidang selain sistem informasi. UML adalah
bahasa pemodelan standar atau kumpulan teknik-teknik pemodelan untuk
menspesifikasi, mem-visualisasi, meng-konstruksi dan mendokumentasi
hasil kerja dalam pengembangan perangkat lunak (Fowler, 2004). UML lahir
dari penggabungan banyak bahasa pemodelan grafis berorientasi obyek
yang berkembang pesat pada akhir tahun 1980an dan awal 1990an.
Secara sederhana UML digunakan untuk menggambar sketsa sistem.
Pengembang menggunakan UML untuk menyampaikan beberapa aspek dari sebuah
perangkat lunak melalui notasi grafis. UML mendefinisikan notasi dan
semantik. Notasi merupakan sekumpulan bentuk khusus yang memiliki makna
tertentu untuk menggambarkan berbagai diagram piranti lunak dan semantik
mendefinisikan bagaimana bentuk-bentuk tersebut dapat dikombinasikan.
Ada beberapa jenis diagram yang disediakan dalam UML, antara lain adalah
:
- Use-case diagram. Diagram ini berguna untuk menggambarkan interaksi antara pengguna dengan sebuah perangkat lunak
- Activity diagram. Diagram ini berguna untuk menggambarkan prosedurprosedur perilaku perangkat lunak.
- Class diagram. Diagram ini berguna untuk menggambarkan class,
fitur, dan hubungan-hubungan yang terjadi. Pada diagram ini pendekatan
berorientasi obyek memegang peranan yang sangat penting.
- Sequence diagram. Diagram ini berguna untuk menggambarkan
interaksi antar obyek dengan penekanan pada urutan proses atau kejadian.
- State machine diagram. Diagram ini digunakan untuk
menggambarkan bagaimana suatu kejadian mengubah obyek selama masa hidup
obyek tersebut.
- Component diagram. Diagram ini berguna untuk menggambarkan struktur dan koneksi komponen.
TAHAPAN - TAHAPAN DALAM REKAYASA PERANGKAT LUNAK
Berikut ini kita akan membahas beberapa tahapan dalam Rekayasa
Perangkat Lunak. Seperti yang kita telah ketahui bahwa tahapan dalam RPL
itu ada analysis – design – coding(construction) – testing –
maintenance.Di bawah ini kita akan mencoba untuk membahasnya satu
persatu.
Analisis sistem adalah sebuah teknik pemecahan masalah yang
menguraikan sebuah sistem menjadi komponen-komponennya dengan tujuan
mempelajari seberapa bagus komponen-komponen tersebut bekerja dan
berinteraksi untuk meraih tujuan mereka.
Analisis mungkin adalah bagian terpenting dari proses rekayasa
perangkat lunak. Karena semua proses lanjutan akan sangat bergantung
pada baik tidaknya hasil analisis. Tahapan-tahapan dalam analisis
rekayasa perangkat lunak secara ringkas dapat dilihat pada Gambar
berikut ini.
Ada satu bagian penting yang biasanya dilakukan dalam tahapan
analisis yaitu pemodelan proses bisnis. Model proses adalah model yang
memfokuskan pada seluruh proses di dalam sistem yang mentransformasikan
data menjadi informasi (Harris, 2003). Model proses juga menunjukkan
aliran data yang masuk dan keluar pada suatu proses. Biasanya model ini
digambarkan dalam bentu Diagram Arus Data (Data Flow Diagram / DFD). DFD
meyajikan gambaran apa yang manusia, proses dan prosedur lakukan untuk
mentransformasi data menjadi informasi.
Umumnya ada empat notasi yang sering digunakan dalam DFD seperti pada penjelasan di bawah ini.
External Entity melambangkan sumber data (dari mana data berasal)
atau penerima informasi (tujuan akhir dari data). Contoh external
entity antara lain konsumen yang memesan suatu produk, manajer yang
mengevaluasi laporan penjualan mingguan, dan lain lain.
Proses adalah serangkaian langkah yang dilakukan untuk
memanipulasi data, misalnya pengumpulan, pengurutan, pemilihan,
pelaporan, peringkasan, analisis dan lain-lain.
Data store adalah tempat untuk menyimpan data untuk digunakan
kemudian. Nama yang pada data store ini merupakan abstraksi dari data
yang disimpan. Namun detil / item data apa saja yang ada, bagaimana cara
akses, atau bagaimana mengorganisasinya tidak dijelaskan dalam notasi
ini.
Data flow menunjukkan aliran data dari satu tempat ke tempat
lain. Perpindahan data ini dapat dari external entity ke proses, antar
proses satu dengan yang lain, dari proses ke data store. Dalam
penggambarannya setiap data flow harus diberi label yang menunjukkan
data apa yang mengalir.
Di dalam pembuatan DFD ada beberapa tahapan yang harus di lakukan
secara berurutan. Apakah tahapan - tahapan itu ?. Coba anda perhatikan
gambar di bawah ini
Context diagram adalah DFD ruang lingkup dari sistem yang
menunjukkan batas-batas sistem, external entitiy yang berinteraksi
dengan sistem dan aliran data utama antara external entity dengan
sistem. Context diagram menggambarkan keseluruhan sistem dalam suatu
proses tunggal. Gambar di bawah ini menunjukkan sebuah contoh context
diagram.
Context diagram pada Gambar diatas tampak hanya ada satu proses
tunggal yang merepresentasikan sistem yang dimodelkan. Pada proses ini
diberi notasi angka 0 untuk menunjukkan ini adalah level paling abstrak
dari sistem. Selain itu ada tiga external entity yaitu customer, kitchen
dan restaurant manager. Ketiganya dapat berperan sebagai sumber data
(dalam contoh di atas adalah customer) atau sebagai penerima informasi
(dalam contoh di atas customer, kitchen, dan restaurant manager). Data
flow yang tampak pada gambar menunjukkan ada satu data flow yang masuk
ke sistem dan ada tiga data flow yang keluar dari sistem. Masing-masing
data flow diberi label yang menunjukkan data apa yang sedang mengalir.
Setelah context diagram terbentuk dengan benar maka langkah
selanjutnya adalah merinci context diagram tersebut dalam DFD Level 0.
DFD Level 0 adalah DFD yang merepresentasikan proses-proses, data flow
dan data storage utama di dalam sistem. DFD Level 0 ini akan digunakan
sebagai dasar untuk membangun DFD yang level dibawahnya (Level 1, 2, 3,
.. dst) atau biasa disebut sebagai dekomposisi DFD. Gambar 3.10
merupakan DFD level 0 dari context-diagram pada gambar di bawah ini.
Pada gambar diatas tampak adanya pemecahan pada proses dari yang
semula hanya satu menjadi empat. Masing-masing proses diberi nomor kode
1.0, 2.0, 3.0 dan 4.0. Jumlah external entity harus tetap yaitu 3
demikian pula data flow yang keluar dan masuk (input dan output) ke
dalam sistem harus sama dengan pada context diagram. Sedangkan data flow
yang berada di dalam sistem (yang mengalir antar proses dan atau data
storage) tergantung pada proses dan data storage yang terlibat. Ada dua
data storage yaitu Goods Sold File dan Inventory File. Kedua data
storage ini digunakan untuk menyimpan data dari suatu proses. Data ini
juga akan dibaca / diakses oleh proses yang lain. Sebagai contoh data
storage Inventory File berisi data hasil proses 3.0 (Update Inventory
File). Data ini akan digunakan proses 4.0 (Produce Management Reports)
untuk membuat laporan yang akan disampaikan pada Restaurant Manager.
SUMBER : BSE RPL JILID 1 ( EDISI UPDATE )
0 comments:
Post a Comment