Proses Perancangan Interaksi

"TUGAS INTERAKSI MANUSIA DAN KOMPUTER"

Di kesempatan kali ini saya akan sedikit menjelaskan tentang bebetapa permodelan dalam proses perancangan interaksi (Model Siklus Hidup dan Proses) .

1. Waterfall.
   Nama model ini sebenarnya adalah “Linear Sequential Model”. Model ini sering disebut dengan “classic life cycle” atau model waterfall. Model ini adalah model yang muncul pertama kali yaitu sekitar tahun 1970 sehingga sering dianggap kuno, tetapi merupakan model yang paling banyak dipakai didalam Software Engineering (SE). Model ini melakukan pendekatan secara sistematis dan urut mulai dari level kebutuhan sistem lalu menuju ke tahap analisis, desain, coding, testing / verification, dan maintenance. Disebut dengan waterfall karena tahap demi tahap yang dilalui harus menunggu selesainya tahap sebelumnya dan berjalan berurutan. Sebagai contoh tahap desain harus menunggu selesainya tahap sebelumnya yaitu tahap requirement. Secara umum tahapan pada model waterfall dapat dilihat pada gambar berikut :

   
   

   

   Gambar Model Waterfall.

    
   
   

   Gambar di atas adalah tahapan umum dari model proses ini. Akan tetapi Roger S. Pressman memecah model ini menjadi 6 tahapan meskipun secara garis besar sama dengan tahapan-tahapan model waterfall pada umumnya. Berikut adalah penjelasan dari tahap-tahap yang dilakukan di dalam model ini menurut Pressman:

   • System / Information Engineering and Modeling. Permodelan ini diawali dengan mencari kebutuhan dari keseluruhan sistem yang akan diaplikasikan ke dalam bentuk software. Hal ini sangat penting, mengingat software harus dapat berinteraksi dengan elemen-elemen yang lain seperti hardware, database, dsb. Tahap ini sering disebut dengan Project Definition.
   • Software Requirements Analysis. Proses pencarian kebutuhan diintensifkan dan difokuskan pada software. Untuk mengetahui sifat dari program yang akan dibuat, maka para software engineer harus mengerti tentang domain informasi dari software, misalnya fungsi yang dibutuhkan, user interface, dsb. Dari 2 aktivitas tersebut (pencarian kebutuhan sistem dan software) harus didokumentasikan dan ditunjukkan kepada pelanggan.
   • Design. Proses ini digunakan untuk mengubah kebutuhan-kebutuhan diatas menjadi representasi ke dalam bentuk “blueprint” software sebelum coding dimulai. Desain harus dapat mengimplementasikan kebutuhan yang telah disebutkan pada tahap sebelumnya. Seperti 2 aktivitas sebelumnya, maka proses ini juga harus didokumentasikan sebagai konfigurasi dari software.
   • Coding. Untuk dapat dimengerti oleh mesin, dalam hal ini adalah komputer, maka desain tadi harus diubah bentuknya menjadi bentuk yang dapat dimengerti oleh mesin, yaitu ke dalam bahasa pemrograman melalui proses coding. Tahap ini merupakan implementasi dari tahap design yang secara teknis nantinya dikerjakan oleh programmer.
   • Testing / Verification. Sesuatu yang dibuat haruslah diujicobakan. Demikian juga dengan software. Semua fungsi-fungsi software harus diujicobakan, agar software bebas dari error, dan hasilnya harus benar-benar sesuai dengan kebutuhan yang sudah didefinisikan sebelumnya.
   • Maintenance. Pemeliharaan suatu software diperlukan, termasuk di dalamnya adalah pengembangan, karena software yang dibuat tidak selamanya hanya seperti itu. Ketika dijalankan mungkin saja masih ada errors kecil yang tidak ditemukan sebelumnya, atau ada penambahan fitur-fitur yang belum ada pada software tersebut. Pengembangan diperlukan ketika adanya perubahan dari eksternal perusahaan seperti ketika ada pergantian sistem operasi, atau perangkat lainnya.

   Mengapa model ini sangat populer??? Selain karena pengaplikasian menggunakan model ini mudah, kelebihan dari model ini adalah ketika semua kebutuhan sistem dapat didefinisikan secara utuh, eksplisit, dan benar di awal project, maka SE dapat berjalan dengan baik dan tanpa masalah. Meskipun seringkali kebutuhan sistem tidak dapat didefinisikan seeksplisit yang diinginkan, tetapi paling tidak, problem pada kebutuhan sistem di awal project lebih ekonomis dalam hal uang (lebih murah), usaha, dan waktu yang terbuang lebih sedikit jika dibandingkan problem yang muncul pada tahap-tahap selanjutnya.

   Meskipun demikian, karena model ini melakukan pendekatan secara urut / sequential, maka ketika suatu tahap terhambat, tahap selanjutnya tidak dapat dikerjakan dengan baik dan itu menjadi salah satu kekurangan dari model ini. Selain itu, ada beberapa kekurangan pengaplikasian model ini, antara lain adalah sebagai berikut:

   • Ketika problem muncul, maka proses berhenti, karena tidak dapat menuju ke tahapan selanjutnya. Bahkan jika kemungkinan problem tersebut muncul akibat kesalahan dari tahapan sebelumnya, maka proses harus membenahi tahapan sebelumnya agar problem ini tidak muncul. Hal-hal seperti ini yang dapat membuang waktu pengerjaan SE.
   • Karena pendekatannya secara sequential, maka setiap tahap harus menunggu hasil dari tahap sebelumnya. Hal itu tentu membuang waktu yang cukup lama, artinya bagian lain tidak dapat mengerjakan hal lain selain hanya menunggu hasil dari tahap sebelumnya. Oleh karena itu, seringkali model ini berlangsung lama pengerjaannya.
   • Pada setiap tahap proses tentunya dipekerjakan sesuai spesialisasinya masing-masing. Oleh karena itu, ketika tahap tersebut sudah tidak dikerjakan, maka sumber dayanya juga tidak terpakai lagi. Oleh karena itu, seringkali pada model proses ini dibutuhkan seseorang yang “multi-skilled”, sehingga minimal dapat membantu pengerjaan untuk tahapan berikutnya.

   Menurut saya, tahapan-tahapan model ini sudah cukup baik dalam artian minimal untuk melakukan SE, maka harus ada tahapan-tahapan ini. Tahapan-tahapan ini jugalah yang digunakan oleh model-model yang lain pada umumnya. Ada filosofi yang mengatakan sesuatu yang sukses diciptakan pertama kali, maka akan terus dipakai di dalam pengembangannya. Hal ini juga berlaku pada waterfall model ini. Mungkin dapat dikatakan bahwa inilah standar untuk melakukan SE.

   Akan tetapi, yang mungkin menjadi banyak pertimbangan mengenai penggunaan dari model ini adalah metode sequential-nya. Mungkin untuk awal-awal software diciptakan, hal ini tidak menjadi masalah, karena dengan berjalan secara berurutan, maka model ini menjadi mudah dilakukan. Sesuatu yang mudah biasanya hasilnya bagus. Oleh karena itu model ini sangat populer. Akan tetapi, seiring perkembangan software, model ini tentu tidak bisa mengikutinya. Yang menjadi kelemahan adalah pada pengerjaan secara berurutan tadi, seperti yang sudah saya utarakan sebelumnya. Kelemahan-kelemahan yang lain juga sudah saya utarakan di atas, atau bahkan masih ada yang lainnya.

   Dari sini, nantinya akan dikembangkan model-model yang lain, bahkan ada tahap evolusioner dari suatu model proses untuk mengatasi kelemahan-kelemahan tadi. Meskipun secara tahapan masih menggunakan standar tahapan waterfall model. Kesimpulannya adalah ketika suatu project skalanya sedang mengarah kecil bisa menggunakan model ini. Akan tetapi kalau sudah project besar, tampaknya kesulitan jika menggunakan model ini.

   
   
2. Model RAD (Rapid Application Development).
   Merupakan model proses pengembangan perangkat lunak secara linear sequential yang menekankan pada siklus pengembangan yang sangat singkat. Jika kebutuhan dipahami dengan baik, proses RAD memungkinkan tim pengembangan menciptakan “sistem fungsional yang utuh” dalam periode waktu yang sangat pendek (kira-kira 60-90 hari).

   
   

   

   Gambar Model RAD

   
   
   Pendekatan RAD model menekankan cakupan :
   • Pemodelan bisnis (Bussiness Modelling).
     Aliran informasi diantara fungsi-fungsi bisnis dimodelkan dengan suatu cara untuk menjawab pertanyaan-pertanyaan berikut : Informasi apa yang mengendalikan proses bisnis ? Kemana informasi itu pergi? Siapa yang memprosesnya ? 
   •  Pemodelan data (Data Modelling).
     Aliran informasi yang didefinisikan sebagai bagian dari fase pemodelan bisnis disaring ke dalam serangkaian objek data yang dibutuhkan untuk menopang bisnis tersebut. Karakteristik/atribut dari masing-masing objek diidentifikasi dan hubungan antara objek-objek tersebut didefinisikan.
   • Pemodelan proses (Process Modelling)Aliran informasi yang didefinisikan dalam fase pemodelan data ditransformasikan untuk mencapai aliran informasi yang perlu bagi implementasi sebuah fungsi bisnis. Gambaran pemrosesan diciptakan untuk menambah, memodifikasi, menghapus atau mendapatkan kembali sebuah objek data. 
   • Pembuatan aplikasi (Application generation).
     Selain menciftakan perangkat lunak dengan menggunakan bahasa pemrograman generasi ketiga yang konvensional, RAD lebih banyak memproses kerja untuk memakai lagi komponen program yang telah ada atau menciftakan komponen yang bias dipakai lagi. Pada semua kasus, alat-alat Bantu otomatis dipakai untuk memfasilitasi kontruksi perangkat lunak. 
   • Pengujian dan pergantian (Testing and turnover).
     Karena proses RAD menekankan pada pemakaian kembali, banyak komponen yang telah diuji. Hal ini mengurangi keseluruhan waktu pengujian. Tapi komponen baru harus diuji.
   Kelemahan RAD model :
   1. Untuk proyek dengan skala besar, RAD membutuhkan sumber daya manusia yang cukup untuk membentuk sejumlah tim RAD.
   2. RAD membutuhkan pengembang dan pemakai yang mempunyai komitmen untuk melaksanakan aktivitas melengkapi sistem dalam kerangka waktu yang singkat.
   3. Akan menimbulkan masalah jika sistem tidak dapat dibuat secara modular.
   4. RAD tidak cocok digunakan untuk sistem yang mempunyai resiko teknik yang tinggi.
3.  V-Model
   Pada tahun 1986, Federal Ministry for Defense negara Jerman memulai dua proyek teknologi informasi. Kedua proyek tersebut adalah software development environment for information system (SEU-IS) dan software development environment for weapon and weapon delivery systems (SEU-WS). Dalam pelaksanaan kedua proyek tersebut ada beberapa goal yang ingin dicapai yaitu:
   
   

   

   Gambar V-Model

   • Membuat biaya dan proses-proses yang ada pada seluruh software development process menjadi jelas.
   • Menerapkan minimum standard untuk menjamin kualitas software yang dihasilkan.
   • Melakukan standarisasi dan membuat software development process lebih transparan.
   
   
   V Model dikembangkan untuk mewujudkan goal di atas. Hal ini disebabkan karena model-model yang ada pada masa itu dirasa belum sesuai dengan kebutuhan yang ada.
   Variant pertama V Model muncul pada tahun 1988 sebagai akibat dari proyek SEU-WS. Lalu pada tahun 1991, variant V Model yang lebih baru muncul karena proyek SEU-IS. Hal ini terus berlangsung. Begitu dirasa adanya kebutuhan untuk melakukan perubahan maka akan dikembangkan variant V Model yang baru.
   Variant V Model yang akan dibahas dengan lebih spesifik di sini adalah variant V Model yang dikembangkan pada tahun 1997. Variant V Model ini muncul karena adanya perkembangan pada software development process (misal: object orientation).
   
   Arsitektur V Model terdiri dari 3 tahap. Secara garis besar tahap-tahap tersebut adalah seperti yang akan dijelaskan di bawah ini.
   • Lifecycle process model.
     Lifecycle process model menjawab pertanyaan tentang apa yang harus dilakukan. Termasuk dalam tahap ini adalah menetapkan activity apa yang harus dilakukan, hasil apa yang diperoleh dari activity tersebut, dan apa saja yang ada di dalam hasil tersebut.
   • Allocation of methods.
     Allocation of methods menjawab pertanyaan bagaimana cara melakukannya. Termasuk dalam tahap ini adalah penentuan method apa yang akan digunakan untuk melakukan activity yang sudah ditetapkan pada tahap lifecycle process model. 
   • Functional tool requirements.
     Functional tool requirements menjawab pertanyaan tool apa yang bisa digunakan untuk melakukannya. Termasuk dalam tahap ini adalah penentuan functional characteristic apa yang harus dimiliki oleh tool yang akan digunakan untuk melakukan activity pada tahap lifecycle process model.
   Pada setiap tahap di atas ada empat area of functionality yang dikenal dengan sebutan submodel. Keempat submodel tersebut adalah:
   • Project management (PM).
     Submodel ini merencanakan, me-monitor, dan mengontrol proyek. Selain itu submodel ini juga mengirimkan informasi pada submodel yang lain. 
   • System development (SD).
     Submodel ini men-develop software yang ingin dibuat.
   • Quality assurance (QA).
     Submodel ini menspesifikasikan standar kualitas yang diinginkan dan memberitahukannya pada submodel yang lain. Submodel ini juga menspesifikasikan contoh test case dan kriteria untuk memastikan bahwa software yang dihasilkan dan proses untuk menghasilkannya berdasarkan dan sesuai dengan standar yang telah ditetapkan.
   • Configuration management (CM).
     Submodel ini melakukan administrasi software yang dihasilkan.
     
     Gambaran tentang tahap, submodel, dan hubungan antara tahap dan submodel dalam V Model dapat dilihat pada gambar di bawah.
     
4. Model Rancangan Interaksi Sederhana.
   
   Pada model rancangan interaksi sederhana ini input atau masukan hanya memiliki satu titik. yang mana masukan tersebut diidentifikasikan apakah sesuai dengan kebutuhan, lalu didesain sesuai dengan persyaratan yang telah ditetapkan. Setelah diDesain rancangan tersebut dibangun dan harus interaktif. Setelah itu barulah rancangan tersebut dievaluasi.
   
        Evaluasi dapat dilakukan dimana saja, rancangan yang telah di evakuasi dapat kambali didesain ulang atau apakah rancangan tersebut tidak sesuai dengan kebutuhan user, maka alur tersebut akan terus berputar hingga pada tahap evaluasi tidak lagi terjadi kesalahan, baik dalam penetapan kebutuhan user maupun pendesainannya, sehingga pada tahap evaluasi terciptalah sebuah hasil akhir yang valid.
   

   

   Gambar Rancangan Model Interaksi Sederhana

5. Model Siklus Hidup Star.
   
   
   
   
   Dalam Siklus permodelan ini pengujian dilakukan terus menerus, tidak harus dikahir. Misalnya dimulai dari menentukan kosep desain (conceptual design ) dalam proses ini akan langsung terjadi evaluasi untuk langsung ternilai apakah sudah sesuai dengan kebutuhan user, bila belum maka akan terus berulang di evaluasi hingga benar-benar pas, selanjutnya apabila sudah pas, maka dari tahap evaluasi yang pertama akan lanjut ke proses yg selanjutnya yakni requirements/specification yakni memverifikasikan persyaratan rancangan tersebut, dan pada tahap itu juga langsung terjadi pengevaluasian seperti tahap pertama, dan selanjutnya akan tetap sama terjadi pada tahapan-tahapan selanjutnya yakni task analysis/fungsion analysis, pengimplementasian, prototyping hingga pada akhirnya terciptalah sebuah aplikasi yang sesuai dengan kebutuhan user.
   Intinya pada rancangan model ini pengevaluasian dilakukan disetiap tahapan tidak hanya pada tahapan akhir seperti model-model rancangan yang lainnya.
   
   

   
   
   
   

   Gambar Model Siklus Hidup Star.

   
   
   Sumber:
   http://ngakan-blog.blogspot.com/2012/09/model-proses-pengembangan-perangkat.html
   http://theresianihan.blogspot.com/
   http://riezqa.blogspot.com/2007/07/software-engineering-model.html
   http://en.wikipedia.org/wiki/V-Model