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