RPL :MEMAHAMI PEMODELAN PERANGKAT LUNAK DAN PROTOTYPING

Berbagi Ilmu    Rekayasa Perangkat Lunak    Comment   

PROTOTYPING DAN PEMODELAN PERANGKAT LUNAK

Pemodelan Perangkat Lunak

Hai Sobat, Kali ini kita akan belajar tentang Prototyping dan Pemodelan Perangkat Lunak. Dalam hal ini kita juga akan membahas model-model pemodelan perangkat lunak, meliputi; Model Waterfall, Model Spiral, Model Rational Unified Process (RUP), Rappid Application Development (RAD). Langsung saja kita masuk pada pembahasan, Let's go....

PROTOTYPING PERANGKAT LUNAK

Dalam proses analisis proses pendekatan dilakukan, dan salah satunya adalah prototyping. Prototyping adalah sebuah proses pengumpulan persyaratan, pengaplikasian prinsip analisis, dan penyusunan model perangkat lunak yang akan dibangun untuk penilaian dan pengembangan. Akhirnya ada lingkungan yang membutuhkan konstruksi prototipe pada awal analisis, karena model adalah satu-satunya alat dimana persyaratan dapat ditarik secara efektif. Model tersebut kemudian dikembangkan dalam perangkat lunak produksi.

Ada empat model prototype:

1.      Prototype kertas, menggambarkan system dengan menggunakan media kertas. Prototype kertas tidak bisa diuji coba dan diimplementasikan.

2.      Prototype berbasis PC, memanfaatkan program aplikasi untuk menunjukkan interaksi manusia dan komputer.

3.      Prototype kerja, merupakan implementasi sebagian fungsi system yang ingin dilihat unjuk kerjanya, dan diwujudkan dalam sebuah program.

4.      Prototype program, program benar-benar dibuat dan dapat berfungsi dengan baik.

Selain itu, program juga terus menerus ditambah dan dilengkapi.

Paradigma prototyping dapat terbatas atau tidak terbatas. Pendekatan terbatas disebut throaway prototyping. Dengan menggunakan pendekatan ini, prototipe sebagai sebuah demonstrasi dari sebuah persyaratan. Sedangkan pendekatan tidak terbatas, yang disebut juga evolutionary prototyping., menggunakan prototipe sebagai bagian pertama dari aktivitas analisis yang akan diteruskan ke dalam desain dan konstruksi. Sebelum pendekatan terbatas atau tidak terbatas dilaksanakan perlu dilakukan apakah sistem yang akan dibangun dapat menerima protoyping atau tidak. Sejumlah faktor perlu diperhatikan, diantaranya: area aplikasi, kompleksitas aplikasi, karakteristik pelanggan, dan karakteristik proyek.

Beberapa kelebihan/manfaat yang bisa diambil bila kita menggunakan prototyping antara lain :

1.      Adanya komunikasi yang intensif antara pengembang dan user

2.      Membantu dalam analisis, karena kebutuhan user telah dipahami dengan baik oleh pengembang sehingga dapat meminimalkan salah persepsi antara kedua pihak.

3.      Peran user meningkat, karena user dapat melakukan evaluasi dan masukan baru setiap saat.

4.      Pengembangan lebih cepat, karena program bisa langsung dibuat dan user dapat melihat setiap tahap pembuatan program.

5.      Mudah dalam implementasinya, karena user sudah sejak awal terlibat sehingga sudah akrab dan tidak merasa asing terhadap program.

Sedangkan kelemahan memakai prototype adalah :

1.      User sibuk, karena user dan pengembang harus sama-sama memiliki komitmen untuk sering bertemu dan membahas kebutuhannya

2.      User ingin program segera selesai sehingga pengembang sering mengabaikan dokumentasi

3.      User berharap terlalu banyak, seringnya evaluasi dan komunikasi membuat user sering berubah fikiran dan tidak pasti akan kebutuhannya.

PEMODELAN REKAYASA PERANGKAT LUNAK

 Di dalam suatu industri dikenal berbagai macam proses, demikian juga halnya dengan industri perangkat lunak. Perbedaan proses yang digunakan akan menguraikan aktivitasaktivitas proses dalam cara-cara yang berlainan. Perusahaan yang berbeda menggunakan proses yang berbeda untuk menghasilkan produk yang sama. Tipe produk yang berbeda mungkin dihasilkan oleh sebuah perusahaan dengan menggunakan proses yang berbeda. Namun beberapa proses lebih cocok dari lainnya untuk beberapa tipe aplikasi. Jika proses yang salah digunakan akan mengurangi kualitas kegunaan produk yang dikembangkan. 

Karena banyaknya variasi dalam model proses yang digunakan maka tidak mungkin menghasilkan gambaran-gambaran yang reliabel untuk alokasi biaya dalam aktivitas-aktivitas ini. 

Modifikasi perangkat lunak biasanya lebih dari 60 % dari total biaya pembuatan perangkat lunak. Presentasi ini terus bertambah karena lebih banyak perangkat lunak dihasilkan dan dipelihara. Pembuatan perangkat lunak untuk suatu perubahan adalah penting.

Proses perangkat lunak komplek dan melibatkan banyak aktivitas. 

Seperti produk, proses juga memiliki atribut dan karakteristik seperti : 

•       Understandability, yaitu sejauh mana proses secara eksplisit ditentukan dan bagaimana kemudahan definisi proses itu dimengerti. 

•       Visibility, apakah aktivitas-aktivitas proses mencapai titik akhir dalam hasil yang jelas sehingga kemajuan dari proses tersebut dapat terlihat nyata/jelas 

•       Supportability, yaitu sejauh mana aktivitas proses dapat didukung oleh CASE 

•       Acceptability, apakah proses yang telah ditentukan oleh insinyur dapat diterima dan digunakan dan mampu bertanggung jawab selama pembuatan produk perangkat lunak 

•       Reliability, apakah proses didesain sedimikian rupa sehingga kesalahan proses dapat dihindari sebelum terjadi kesalahan pada produk. 

•       Robustness, dapatkah proses terus berjalan walaupun terjadi masalah yang tak diduga 

•       Maintainability, dapatkah proses berkembang untuk mengikuti kebutuhan atau perbaikan 

•       Rapidity, bagaimana kecepatan proses pengiriman sistem dapat secara lengkap memenuhi spesifikasi. 

Tidak mungkin untuk mengoptimalkan semua atribut proses secara serentak. Contohnya, jika pengembangkan proses cepat dilakukan mungkin kita perlu mengurangi visibility proses karena pembuatan proses yg nyata berarti pembuatan dokumen secara teratur.

Ini akan memperlambat proses. 

Pemodelan dalam rekayasa perangkat lunak merupakan suatu hal yang dilakukan ditahap awal dan akan mempengaruhi pekerjaan-pekerjaan selanjutnya dalam rekayasa perangkat lunak tersebut.

1.     Model Waterfall

Langkah-langkah yang penting dalam model ini adalah  

•       Penentuan dan analisis spesifikasi 

Jasa, kendala dan tujuan dihasilkan dari konsultasi dengan pengguna sistem. Kemudian semuanya itu dibuat dalam bentuk yang dapat dimengerti oleh user dan staf pengembang.

•       Desain sistem dan perangkat lunak 

Proses desain sistem membagi kebutuhan-kebutuhan menjadi sistem perangkat lunak atau perangkat keras. Proses tersebut menghasilkan sebuah arsitektur sistem keseluruhan. Desain perangkat lunak termasuk menghasilkan fungsi sistem perangkat lunak dalam bentuk yang mungkin ditransformasi ke dalam satu atau lebih program yang dapat dijalankan.

•       Implementasi dan ujicoba unit 

Selama tahap ini desain perangkat lunak disadari sebagai sebuah program lengkap atau unit program. Uji unit termasuk pengujian bahwa setiap unit sesuai spesifikasi.

•       Integrasi dan ujicoba sistem 

Unit program diintegrasikan dan diuji menjadi sistem yang lengkap untuk menyakinkan bahwa persyaratan perangkat lunak telah dipenuhi. Setelah ujicoba, sistem disampaikan ke pelanggan.

•       Operasi dan pemeliharaan 

Normalnya, ini adalah phase yang terpanjang. Sistem dipasang dan digunakan. Pemeliharaan termasuk pembetulan kesalahan yang tidak ditemukan pada langkah sebelumnya. Perbaikan implementasi unit sistem dan peningkatan jasa sistem sebagai kebutuhan baru ditemukan.

Gambar: Pemodelan Waterfall

Dalam prakteknya, setiap langkah sering tumpang tindih dan saling memberi informasi satu sama lain. Proses perangkat lunak tidak linier dan sederhana tapi mengandung urutan iterasi dari aktivitas pengembangan. Selama di langkah terakhir, perangkat lunak telah digunakan. Kesalahan dan kelalaian dalam menentukan kebutuhan perangkat lunak original dapat diatasi

Sayangnya, model ini banyak mengandung iterasi sehingga membuat sulit bagi pihak manajemen untuk memeriksa seluruh rencana dan laporan. Maka dari itu, setelah sedikit iterasi, biasanya bagian yang telah dikembangkan akan dihentikan dan dilanjutkan dengan langkah pengembangan selanjutnya. Masalah-masalah selama resolusi selanjutnya, dibiarkan atau diprogram. Pemberhentian yang prematur dari persyaratan akan berarti bahwa sistem tidak akan sesuai dengan keinginan user. Mungkin juga sistem terstruktur secara jelek yang sebenarnya merupakan masalah desain akan dibiarkan karena terkalahkan oleh trik implementasi.

Masalah pendekatan waterfall adalah ketidakluwesan pembagian project ke dalam langkah yang nyata/jelas. Sistem yang disampaikan kadang-kadang tidak dapat digunakan sesuai keinginan customer. Namun demikian model waterfall mencerminkan kepraktisan engineering. Konsekuensinya, model proses perangkat lunak yang berdasarkan pada pendekatan ini digunakan dalam pengembangan sistem perangkat lunak dan hardware yang luas. 

2.     Model Spiral

Model spiral dibagi menjadi sejumlah aktivitas kerangka kerja, disebut juga wilayah tugas, antara tiga sampai 6 wilayah tugas :

§  Komunikasi pelanggan

Tugas-tugas yang dibutuhkan untuk membangun komunikasi yang efektif antara pengembang dan pelanggan

§  Perencanaan

Tugas-tugas yang dibutuhkan untuk mendefinisikan sumber-sumber daya, ketepatan waktu dan proyek informasi lain yang berhubungan

§  Analisis resiko

Tugas-tugas yang dibutuhkan untuk memperkirakan resiko-resiko, baik manajemen maupun teknis.

§  Perekayasaan

Tugas-tugas yang dibutuhkan untuk membangun satu atau lebih representasi aplikasi.

§  Konstruksi dan peluncuran

Tugas-tugas yang dibutuhkan untuk mengkonstruksi, menguji, memasang dan memberikan pelayanan pada pemakai (missal pelatihan dan dokumentasi).

§  Evaluasi pelanggan

Tugas-tugas yang dibutuhkan untuk memperoleh umpan balik dari pelanggan dengan didasarkan pada evaluasi representasi perangkat lunak, yang dibuat selama masa perekayasaan dan diimplementasikan selama masa pemasangan.

Model spiral menjadi sebuah pendekatan yang realistis bagi perkembangan sistem dan perangkat lunak skala besar. Karena perangkat lunak terus bekerja selama proses bergerak, pengembang dan pemakai memahami dan bereaksi lebih baik terhadap resiko dari tiap tingkat evolusi. peluncuran

Gambar. Model spiral [msr313]

3.     Rational Unified Process (RUP)

Rational Unified Process adalah proses rekayasa perangkat lunak yang menyediakan pendekatan disiplin untuk menandai tugas-tugas dan tanggung jawab dalam pengembangan organisasi. RUP berfokus pada perangkat lunak kualitas tinggi yang mengakomodasi kebutuhan end user dengan jadwal dan anggaran biaya  yang dapat diprediksikan.

RUP meningkatkan produktivitas team dengan menyediakan kemudahan bagi setiap anggota team untuk mengakses pengetahuan yang digunakan untuk aktivitas pengembangan sehingga semua anggota team turut ambil bagian dalam pengembangan perangkat lunak.  

             

Gambar. Rational Unified Process [msr313]

§  Business modeling

      Masalah terbesar dalam usaha pengembangan bisnis adalah komunitas bisnis dengan perekayasa perangkat lunak tidak saling berkomunikasi dengan baik. Hal ini mengakibatkan output dari dunia bisnis tidak digunakan untuk input rekayasa software dengan semestinya demikian pula sebaliknya. RUP mengatasi masalah ini dengan menyediakan bahasa dan proses umum untuk kedua komunitas ini yang menunjukkan bagaimana membuat dan memelihara perencanaan langsung antara model bisnis dengan perangkat lunak.

 Dalam bisnis modeling kita mendokumentasikan proses bisnis menggunakan use case bisnis yang menjamin pengertian yang sama diantara pihak-pihak pengambil keputusan mengenai proses bisnis apa yang dibutuhkan untuk mendukung pengembangan organisasi.  

§  Requirements

Requirements mendeskripsikan apa yang seharusnya dilakukan oleh sistem dan memastikan bahwa pengembang dan pelanggan menyetujui deskripsi tersebut. Untuk mencapai hal ini kadang kita harus memaksakan pemunculan, pengorganisasian dan pendokumentasian permintaan; melacak dan mendokumentasikan penawaran serta pengambilan keputusan.

§  Analysis and design

Analisis dan desain menunjukkan bagaimana sistem akan direalisasikan dalam fase implementasi. Kita ingin membangun sistem yang :

-          membentuk tugas dan fungsi sesuai spesifikasi use case

-          memenuhi semua permintaan (requirements)

-          terstruktur dengan kuat

Analisis dan desain menghasilkan model desain dan model analisis. Desain model berlaku sebagai blueprint yang menggambarkan bagaimana source code disusun dan ditulis.

§  Implementation

Tujuan implementasi adalah :

-          Mendefinisikan pengorganisasian kode

-          Mengimplementasikan kelas dan obyek ke dalam bentuk komponen 

-          Menguji pengembangan komponen

-          Mengintegrasikan hasil produksi individual implentasi ke dalam sebuah sistem tereksekusi 

§  Test

Pengujian bertujuan untuk :

-          Memeriksa interaksi antar obyek

-          Memeriksa usaha penyatuan seluruh komponen perangkat lunak

-          Memeriksa apakah semua requirement telah diimplementasikan dengan benar

-          Mengidentifikasi dan memastikan kesalahan telah diketahui sebelum peluncuran program.

§  Configuration and change management

Berisi panduan untuk mengatur berbagai variasi perkembangan sistem perangkat lunak, pelacakan versi mana yang digunakan dalam pembuatan perangkat lunak, pembuatan program individual atau keseluruhan berdasar spesifikasi yang diminta user dan kebijakan pengembangan perangkat lunak

§  Environment

Menyediakan lingkungan pendukung bagi pengembangan program (meliputi proses dan tool) yang dibutuhkan oleh team pengembang. Environment berfokus pada aktivitas untuk mengkonfigurasi proses ke dalam proyek, panduan pendukung untuk pengembangan proyek.

§  Deployment

Deployment mensukseskan peluncuran produk dan penyampaian perangkat lunak ke pengguna akhir. Deployment meliputi:

-          Pengemasan perangkat lunak

-          Pendistribusian perangkat lunak

-          Penginstallan perangkat lunak

-          Bantuan dan dukungan bagi pengguna

4.     Rapid Application Development (RAD)

Rapid Application Development (RAD) adalah salah satu metode pengembangan suatu sistem informasi dengan waktu yang relatif singkat. Untuk pengembangan suatu sistem informasi yang normal membutuhkan waktu minimal 180 hari, akan tetapi dengan menggunakan metode RAD suatu sistem dapat diselesaikan hanya dalam waktu 30-90 hari.

Tujuan utama dari semua metode pengembanga sistem adalah memberikan suatu sistem yang dapat memenuhi harapan dari para pemakai, akan tetapi sering kali di dalam melakukan pengembangan suatu sistem tidak melibatkan para pemakai sistem secara langsung, sehingga hal ini menyebabkan sistem informasi yang dibuat jauh dari harapan pemakai yang dapat berakibat sistem tersebut walaupun dapat diterima tetapi para pemakai enggan untuk menggunakannya atau bahkan para pemakai menolak untuk menggunakannya.

Pada saat RAD diimplementasikan, maka para pemakai bisa menjadi bagian dari keseluruhan proses pengembangan system dengan bertindak sebagai pengambil keputusan pada setiap tahapan pengembangan. RAD bisa menghasilkan suatu system dengan cepat karena sistem yang dikembangkan dapat memenuhi keinginan dari para pemakai sehingga dapat mengurangi waktu untuk pengembangan ulang setelah tahap implementasi.

Metode RAD mempunyai 3 tahapan utama seperti yang terlihat pada gambar dibawah

ini : 

             

Gambar. Tahapan RAD [msr313]

Tahapan-tahapan RAD :

1.      Requirements planning ( rencana kebutuhan)

Pada tahap ini, user dan analyst melakukan semacam pertemuan untuk melakukan identifikasi tujuan dari aplikasi atau system dan melakukan identifikasi kebutuhan informasi untuk mencapai tujuan. Hal terpenting dalam tahap ini adalah adanya keterlibatan dari kedua belah pihak, bukan hanya sekedar persetujuan akan proposal yang sudah dibuat. Untuk lebih jauh lagi, keterlibatan user bukan hanya dari satu tingkatan pada suatu organisasi, melainkan beberapa tingkatan organisasi sehingga informasi yang dibutuhkan untuk masing-masing user dapat terpenuhi dengan baik.  

2.      Design workshop (proses desain)

Pada tahap ini adalah melakukan proses desain dan melakukan perbaikan-perbaikan apabila masih terdapat ketidaksesuaian desain antara user dan analyst. Untuk tahap ini maka keaktifan user yang terlibat sangat menentukan untuk mencapai tujuan, karena user bisa langsung memberikan komentar apabila terdapat ketidaksesuaian pada desain. Biasanya, user dan analyst berkumpul menjadi satu dan duduk di meja melingkar dimana masing-masing orang bias melihat satu dengan yang lain tanpa ada halangan.

3.      Implementation (implementasi)

Setelah desain dari sistem yang akan dibuat sudah disetujui baik itu oleh user dan analyst, maka pada tahap ini programmer mengembangkan desain menjadi suatu program. Setelah program selesai baik itu sebagian maupun secara keseluruhan, maka dilakukan proses pengujian terhadap program tersebut apakah terdapat kesalahan atau tidak sebelum diaplikasikan pada suatu organisasi. Pada saat ini maka user bias memberikan tanggapan akan sistem yang sudah dibuat serta persetujuan mengenai sistem tersebut.