Bayangkan anda ditunjuk sebagai penanggung jawab acara arisan di RT anda. Andapun mulai melakukan perencanaan arisan, dan salah satu hal yang harus diperhatikan adalah tempat. Biasanya, arisan dilakukan dirumah sang penanggung jawab acara. Namun ternyata hal itu mustahil, karena peserta arisan tiba-tiba membludak *lebay*. Karena berlebihan jika anda harus membeli tanah/membangun kamar untuk acara tersebut, anda memutuskan untuk menyewa sebuah ruangan didekat komplek anda.

Ketika hendak menyewa tempat tersebut, anda dilanda kekhawatiran mengenai ketersediaan meja, kursi dan perlengkapan lain yang dibutuhkan untuk arisan. Namun ternyata, si penyewa tersebut memiliki paket yang dapat menyediakan perlengkapan tambahan jika dibutuhkan. Akhirnya, andapun tidak perlu pusing. Dengan membayarkan suatu biaya, anda dapat memperoleh ruangan sekaligus peralatannya.

Cloud computing atau biasa disebut cloud serupa seperti tempat tersebut. Ketika kita tidak ingin memecah konsentrasi kita untuk mengurusi permasalahan penyediaan resource (storage, development platform), kita dapat menggunakan cloud untuk menyelesaikan permasalahan tersebut.

Cloud muncul karena semakin berkembangnya teknologi dan meningkatnya kebiasaan+kepercayaan orang terhadap jaringan internet. Secara umum, terdapat beberapa hal yang membuat cloud diminati:

1. Tidak perlu memikirkan pengelolaan resource.
2. Memiliki pembayaran subscription/pay-as-you-go/on-demand dengan harga yang relatif kecil dibandingkan dengan resource on-premise yang harus diinvestasikan diawal dengan biaya yang besar.
3. Ketika kita menyewa suatu resource, kita dapat menambah kapasitas resource ketika dibutuhkan atau melepas resource tersebut jika tidak dibutuhkan.

Cloud memiliki tiga bentuk besar yaitu:

1. Infrastructure as a Service (Iaas). Bentuk ini menyediakan infrastuktur kepada penggunanya yang dapat berupa storage, server dll.
2. Platform as a Service (Paas). Bentuk ini menyediakan platform untuk mengembangkan suatu perangkat lunak. Secara kasar, Paas ini dapat menyediakan lingkungan pemrograman seperti PHP atau menyediakan lingkungan pengembangan perangkat lunak tanpa menggunakan bahasa pemrograman (melalui wizard yang disediakan/langkah-langkah tertentu).
3. Software as a Service (Saas). Bentuk ini menyediakan perangkat lunak kepada pengguna. Contohnya mulai dari email service milik google/yahoo atau perangkat lunak enterprise milik salesforce.com/zoho.

Cloud memiliki beberapa karakteristik seperti multi-tenant, scalable serta konfigurable.

JMS atau Java Message Service adalah sebuah Java API yang menyediakan fungsi kepada aplikasi untuk membuat, mengirim dan menerima pesan. Java API, yang didesain oleh Sun dan beberapa perusahaan partner, mendefinisikan beberapa interface umum dan semantik yang menyediakan program berbahasa Java untuk komunikasi dengan implementasi messaging lainnya.

JMS API ini meminimalisir konsep yang harus dipelajari oleh programmer untuk menggunakan messaging namun menyediakan cukup fitur-fitur untuk aplikasi messaging yang rumit. JMS API ini menyediakan komunikasi yang tidak hanya loosely coupled namun juga:
-    Asynchronous. Penyedia JMS dapat mengirim pesan kepada client saat pesan itu tiba sehingga client tidak perlu meminta pesan untuk mendapatkannya.
-    Reliable. JMS API dapat meyakinkan bahwa pesan dikirim sekali dan hanya sekali.

Spesifikasi JMS dapat dilihat di <a href=”http://java.sun.com/products/jms/”>sini</a>.

p2p

Sebelum adanya JMS API, kebanyakan proses messaging mendukung salah satu pendekatan point-to-point atau publish/subscribe. Spesifikasi JMS menyediakan domain yang berbeda untuk setiap pendekatan tersebut dan mendefinisikannya untuk setiap domain. JMS provider standalone dapat mengimplementasikan satu atau keduanya. Sedangkan J2EE provider dapat menyediakan keduanya. Pada kenyataannya implementasi JMS API mendukung baik point-to-point ataupun publish/subscribe, dan JMS client menggunakan kedua domain tersebut dalam aplikasi yang sama. Dengan cara ini JMS API memperluas kekuatannya dan fleksibilitasnya sebagai produk messaging.

Untuk membentuk suatu aplikasi JMS, terdapat model programming JMS API dengan bagian sebagai berikut:
-    Administer object, objek ini ada dua yaitu connection factories dan destinations. Connection factories adalah objek yang digunakan untuk membuat koneksi dengan provider. Connection factory ini mengenkapsulasi beberapa konfigurasi koneksi yang telah didefinisikan oleh administrator. Sepasang connection factories sudah terkonfigurasi sebelumnya dalam J2EE SDK dan dapat diakses ketika awal servis dijalankan. Connection factory merupakan instan dari QueueConnectionFactory atau TopicConnectionFactory interface. Destinations adalah objek yang digunakan client untuk menentukan target pesan bagi yang mengirim dan sumber pesan bagi yang memerlukan pesan.
-    Connection membungkus koneksi virtual dengan penyedia JMS (JMS provider). Koneksi dapat merepresentasikan soket TCP/IP terbuka antara client dan penyedia servis daemon. Koneksi digunakan untuk membuat satu atau lebih session. Seperti connection factories, connection memiliki dua bentuk yaitu implementasi QueueConnection atau TopicConnection.
-    Session adalah conteks untuk membuat dan mendapatkan pesan. Session didapatkan dari connection yang sudah ada.
-    Message producer adalah objek yang dibuat oleh session dan digunakan untuk mengirim pesan ke destination. Untuk point-to-point bentuk implementasi producernya adalah Queue-Sender interface. Untuk publish/subscrib adalah TopicPublisher interface.
-    Message consumer adalah objek yang digunakan oleh session dan digunakan untuk mengirim pesan ke tujuan. Message consumer ini menyediakan kepada JMS client untuk mendaftarkan dirinya ke interest pada destination dengan penyedia JMS. Penyedia JMS mengelola pengiriman pesan dari destination ke consumer yang terdaftar pada destination itu.
-    Message adalah format yang dikirim pada JMS.

Saya sendiri mencoba untuk melakukan ini kadang-kadang. Awalnya sulit, karena pada dasarnya saya orang yang memiliki pemikiran sedikit tertutup (kekeuh kalo bahasa sundanya), namun lama-lama hal tersebut memberikan pemikiran lain yang sebelumnya tidak terpikirkan.

Namun kalau terlalu terjebak pada kalimat tersebut, malah kita bisa-bisa tidak konsisten. Terkadang kita malah menjadi ragu untuk melakukan sesuatu. Karena ada beberapa hal yang memang harus kita lakukan tanpa berfikir. Kita memang harus memikirkan hal yang berlawanan, namun harus tetap berfikir rasional.

Negosiasi merupakan hal yang terjadi dalam suatu rekayasa kebutuhan. Negosiasi ini dapat terjadi karena adanya konflik kepentingan di antara stakeholder dan juga pengembang yang terikat. Negosiasi ini bertujuan untuk mengurangi dan menghilangkan konflik yang terjadi dengan berbagai macam cara. Terdapat beberapa teknik yang dapat digunakan untuk mencapai tujuan akhir yaitu terdapat spesifikasi akhir yang disetujui oleh seluruh stakeholder yang terlibat. Terdapat dua pendekatan yaitu dari sudut komunikasi yang terjadi dan proses yang terjadi dalam requirement engineering.

Ringkasan Artikel

Ringkasan artikel ini terbagi menjadi dua yaitu artikel Negotiation in the Requirements Elicitation and Analysis Process dan Specification and Analysis of Requirement Negotiation Strategy in Software Ecosystems. Artikel-artikel ini menjelaskan mengenai teknik-teknik yang dapat dimanfaatkan dalam melakukan negosiasi requirement. Pada artikel pertama, teknik yang dapat dimanfaatkan adalah Requirement Communication Networks sedangkan pada artikel kedua, teknik yang dapat dimanfaatkan adalah Requirement Negotiation Spiral Model. Persamaan dari teknik-teknik tersebut adalah menjadikan proses negosiasi lebih mudah dalam hal penanganan konflik yang terjadi menggunakan klaim-klaim yang disebutkan. Sedangkan perbedaannya terdapat pada sudut pandanga penyelesaian dimana teknik pertama menyelesaikan dari sudut pandang komunikasi sedangkan teknik kedua menyelesaikan dari sudut pandang proses yang terjadi dalam negosiasi. Berikut ini ringkasan artikel masing-masing teknik.

Teknik Requirement Communication Networks

Gambar 1 Struktur Stakeholder

Komunikasi dalam requirement merupakan hal yang sangat menantang, khususnya ketika sekumpulan orang dan organisasi perlu untuk saling berkolaborasi pada lokasi yang berjauhan. Dalam komunikasi ini tentu saja dibutuhkan suatu teknik yang dapat memfasilitasi semua stakeholder untuk mencapai kesepahaman dari kebutuhan dan solusi yang ditawarkan. Teknik ini harus menangani kurangnya pendekatan dalam memodelkan jaringan stakeholder. Salah satu teknik untuk menangani hal tersebut adalah Requirement Communication Networks.

Requirement Communication Networks (RCN) menyediakan kemampuan untuk analisis dan desain kebutuhan komunikasi antara stakeholder. Pendekatan ini menyediakan bahasa pemodelan untuk menspesifikasikan kebutuhan komunikasi dan rangka untuk mengevaluasi strategi komunikasi serta memilik taktik dan metodologi.

Struktur RCN menggambarkan stakeholder dan jalur komunikasi kebutuhan. Struktur ini merupakan lingkungan perangkat lunak yang terdiri dari aktor, kelompok aktor, dan jalur negosiasi antara kelompok tersebut. Pendekatan diambil menggunakan perspektif negosiasi dalam komunikasi kebutuhan dengan mengasumsikan bahwa jejak persyaratan sesuai dengan kesepakatan antara stakeholder, masing-masing kelompok stakeholder, yang didokumentasikan dalam bentuk spesifikasi. Untuk suatu struktur stakeholder yang terdapat pada gambar 1 dapat memperlihatkan berkas komunikasi kebutuhan yang terjadi.

Gambar 2 Jaringan Komunikasi Kebutuhan Syntax Model

RCN memiliki beberapa syntax. Stakeholder dalam syntax ini terbagi menjadi dua yaitu single party dan multi party. Syntax ini menjelaskan jumlah aspirasi yang terlibat dalam suatu party. Stakeholder dalam multi party juga terbagi menjadi tiga yaitu homogenous, collaborating dan differented. Anggota homogenous multi party memiliki aspirasi yang sama namun tetap memiliki suara masing-masing sehingga tidak terhubung satu dengan yang lain. Anggota collaborating multi party memiliki aspirasi yang berbeda namun mencari persetujuan sehingga terhubung satu dengan yang lain. Anggota differenciate multi party memiliki aspirasi yang berbeda namun bersaing dengan yang lain. Hubungan kebutuhan ini terkomunikasikan melalui suatu jalur. Setiap hubungan tersebut merepresentasikan persetujuan antara party dalam negosiasi kebutuhan. Syntax RCN ini terlihat pada gambar 2.

Dalam menggunakan RCN tersebut terdapat saran dalam menjalankan komunikasi kebutuhan tersebut yang terbagi menjadi tiga bagian yaitu:

- Method Selection

- Tactic Selection

- Strategy Evaluation

RCN memiliki karakteristik menyerupai jaringan mesh. Jaringan mesh digunakan untuk melewatkan informasi dan terdiri dari node dan channel komunikasi. Jaringan mesh ini dapat terbentuk dengan ditentukan atau membentuk sendiri secara dinamis. Properti dari jaringan mesh dapat dilihat pada gambar 3.

Gambar 3 Property Jaringan Mesh

Peningkatan proses dalam RCN menggunakan siklus Plan-Do-Check-Act dengan diagnosis iteratif, desain komunikasi, validasi dan fase roll-out.

Teknik Requirement Negotiation Spiral Model

Dalam suatu requirement elicitaion dan analysis adalah bagian dari requirement engineering yang berfokus kepada domain aplikasi, layanan yang harus disediakan, kebutuhan performansi dan konstrain hardware. Hal tersebut tidak dapat terlepas dari requirement negotiation. Terdapat beberapa metodologi dalam melakukan proses negosiasi diantaranya WinWin dan spiral model.

Gambar 4 Model Spiral Negosiasi

Dalam spiral model ini sangat berkaitan dengan prioritas dan negosiasi. Sebelum sebuah spesifikasi kebutuhan dapat dinegosiasi, terlebih dahulu harus dilakukan prioritas terhadap kebutuhan tersebut.

Proses prioritas bertanggung jawab untuk mengidentifikasi kebutuhan yang paling berharga dan mengurutkannya. Sebagian besar proyek perangkat lunak memiliki banyak calon kebutuhan dibandingkan yang dapat diimplementasi pada batasan waktu dan biaya. Untuk memperoleh kebutuhan yang paling diinginkan, kemampuan sangat penting. Kunci untuk membuat keputusan yang benar adalah membuat prioritas berbagai alternatif. Prioritas ini digunakan dalam negosiasi. Negosiasi merupakan proses menyelesaikan konflik dengan eksplorasi kemungkinan yang dapat terjadi dengan cara menentukan solusi yang dapat memuaskan pihak-pihak yang terlibat.

Proses negosiasi yang diusulkan didasarkan pada model spiral untuk mengakomodasi rekayasa kebutuhan dinamis. Setiap siklus menyelesaikan konflik yang ada dan mencapai resolusi yang lebih baik. Terdapat lima proses dalam proses negosiasi tersebut yang tergambar pada gambar 4, yaitu:

- Identifikasi Conflicts

- Develop Alternatives Solutions

- Elaborate Solutions

- Judgement and Trade-off

Selain model spiral tersebut, terdapat tiga elemen yang harus diperhatikan selama proses negosiasi yaitu:

- Environment. Lingkungan memiliki peranan penting dalam memahami konteks yang berbeda dalam negosiasi.

- Judgement Criteria. Kriteria ini disebutkan beberapa kali ketika menjelaskan flow aktivitas dalam suatu proses negosiasi.

- Resolution Strategy. Strategi resolusi ini berdasarkan mode yang sudah dikenal dari conflict behaviour yang dipropose oleh Thomas.

Analisis Individu

Terdapat beberapa kelebihan dari teknik-teknik yang sudah dijelaskan diatas. RCN merupakan suatu teknik yang melihat suatu proses negosiasi dengan melihat kekuatan stakeholder yang terlibat dan informasi yang berkaitan diantaranya. RCN melihat negosiasi dari sudut pandang komunikasi yang terjadi diantara stakeholder atau kelompok stakeholder.

Spiral model memiliki keuntungan yaitu terjadi pengulangan proses dalam melakukan negosiasi. Sehingga jika terdapat hal yang terlewat atau masih ada negosiasi yang menjadi perhatian dapat dilakukan pengulangan negosiasi kembali. Dengan adanya iterasi ini, terdapat penyebaran pengetahuan bagi untuk stakeholder dan pengembang karena dilakukan secara bertahap. Hasil akhir ini juga merupakan hasil yang terbaik yang dapat diperoleh.

Kesimpulan

Dalam suatu proses pengembangan kebutuhan konflik merupakan hal yang pasti terjadi sehingga harus dilakukan penanganan khusus untuk menanganinya. Teknik-teknik yang ada bertujuan agar konflik yang terjadi dapat terselesaikan dan setiap stakeholder dapat memahami bersama keputusan yang diambil dari alternatif solusi yang ada. Dengan RCN, dapat dilihat komunikasi yang terjadi diantara stakeholder dan urgensitasnya sehingga dapat dicari strategi untuk menyelesaikan suatu konflik. Sedangkan pada model spiral, terdapat beberapa iterasi negosiasi yang dapat menyelesaikan suatu konflik secara bertahap semakin membaik. Pada model spiral ini pada setiap siklus dapat menyelesaikan konflik lebih banyak dan memperbaiki hasil negosiasi sebelumnya.

Daftar Pustaka

[1] Ahmad, S. (2008). Negotiation in Requirements Elicitation and Analysis Process. 19th Australian Conference on Software Engineering (pp. 683-689). Crawley: IEEE.

Fricker, S. (2009). Specification and Analysis of Requirements Negotiation Strategy in Software Ecosystems. Proceedings of the First International Workshp in Software Ecosystem 2009 (pp. 19-33). Zurich: CEUR-WS.

Meja yang selalu menemani..

Consesnsus memiliki dua primitive: propose dan decide. Setiap proses memiliki nilai awal yang mereka ajukan untuk persetujuan bersama, melalui primitive propose.

Nilai yang diajukan hanya diketahui proses itu sendiri dan pengajuan bersifat lokal. Pengajuan ini memicu suatu kejadian broadcast sehingga semua proses bertukar nilai untuk pada akhirnya mencapai kesepakatan. Semua proses yang berjalan harus menentukan satu nilai kesepakatan melalui primitive decide. Nilai ini harus merupakan salah satu dari nilai yang diajukan.

Ada dua algoritma stop-fail: Algoritma pertama menggunakan langkah komunikasi yang sedikit dengan pesan yang banyak. Sedangkan yang kedua sebaliknya, pesannya sedikit namun langkah komunikasinya banyak.

Algoritma consensus yang pertama, Algoritma 5.1, yang dinamakan Flooding Consensus menggunakan abstraksi komunikasi broadcast usaha-terbaik (best-effort broadcast communication abstraction). Ide dari algoritma ini adalah sebagai berikut. Proses-proses yang ada mengeksekusi ronde-ronde secara sekuensial. Setiap proses mengelola himpunan nilai-nilai yang diajukan yang telah ia liat, dan himpunan ini akan terus augmentasikan dari ronde ke ronde. Pada setiap ronde, setiap proses menyebarkan himpunannya ke semua proses menggunakan abstraksi komunikasi broadcast usaha-terbaik. Dengan kata lain proses membanjiri system dengan himpunan proposal yang telah ia liat pada ronde sebelumnya. Ketika proses menerima himpunan proposal dari proses lain, himpunan tersebut akan digabung dengan himpunan miliknya. Sehingga pada setiap ronde, setiap proses mengkalkulasi union dari semua himpunan yang pernah ia terima.

Algoritma 5.2. disebut “Hierarchical Consensus” adalah alternative untuk menerapkan regular consensus. Algoritma ini menarik karena menggunakan pesan yang sedikit dibanding algoritma “Flooding Consensus” dan membiarkan satu proses untuk menentukan sebelum menukar pesan dengan proses yang lain (0-latency). Namun, untuk mencapai keputusan global, untuk setiap proses yang berjalan yang menentukan, algoritma membutuhkan langkah komunikasi N, bahkan dalam situasi tanpa failure. Algoritma 5.2 cukup jika consensus digunakan sebagai implementasi servis oleh himpunan proses server dimana klien cukup puas untuk mendapatkan nilai secepat mungkin, bahkan jika server-server belum menentukan nilai.

Selamat Membaca! Semangat bagi yang menempuh ujian

Sumber:

Introduction to Reliable Distributed Programming by Rachid Guerraoui dan Luís Rodrigues

Ada beberapa aplikasi yang dibundle dalam installer Windows Live ini seperti Windows Live Messenger, Windows Live Mail, Windows Live Movie Maker Beta, dan lain-lain. Saya hanya menginstall aplikasi yang kira-kira saya butuh saja. Aplikasi yang saya install adalah Windows Live Movie Maker Beta, Windows Live Gallery, dan Windows Live Writer.

Aplikasi yang terakhir saya sebutkan cukup baik menurut saya. Aplikasi ini dapat menjadi interface menuliskan blog untuk beberapa blog umum seperti wordpress dan windows live blog. Saya menggunakannya untuk blog wordpress.

Untuk aplikasi desktop, writer ini dapat diandalkan. Kita dapat melihat preview meskipun tidak terkoneksi ke internet. Fitur-fiturnya sama seperti wordpress, kita cukup pilih di bagian kanan layar.

Dan jika kita pilih tab Preview pada kiri bawah layar maka akan menjadi:

Selamat mencoba!

• satu buah kresek item
• satu buah pisin
• satu buah ponsel
• satu buah jam tangan
• satu eksemplar analisis TA
• satu buah hardisk beserta konektornya
• dua buah buku : The Food Traveler’s Guide dan Twilight
• dua buah foto DE yang baru saya temukan kembali
• satu buah kotak DVD modem
• satu plastik berisi 8 DVD kosong
• satu buah kotak broom yang berceceran
• selusin lebih CD ga berguna yang sengaja saya pisahkan namun belum saya urus
• satu gelas berisi koin-koin dan dua buah pulpen
• dua buah binder, salah satunya berisi ksm saya
• dua buah voucher m2 bekas
• dan satu boneka kuda (atau keledai)

bayangkan bagaimana keadaan meja saya saat ini.. dengan laptop sebesar 15″..

Untuk menggunakan teknik source, kita dapat membuka ‘Source’ pada menu bar eclipse kemudian memilih salah satu teknik yang sudah disediakan. Misalkan kita memiliki source seperti ini:

keadaan awal

Dan kita ingin membuat method getter dan setter secara otomatis, maka kita cukup menekan alt+shift+s, kemudian muncul dialog menu. Di dialog ini akan ada teknik source yang bisa kita gunakan. Untuk membuat getter setter  tekan r:

klik kanan, ada beberapa pilihan untuk teknik source

Akan muncul dialog box seperti ini:

dialog box setter and getter

Ada beberapa fitur yang disediakan:

• Kita bisa memilih field apa saja yang kita ingin buat untuk getter dan setter.
• Kita bisa membuat setter untuk field final.
• Kita bisa menentukan tempat di buatnya getter dan setter serta urutannya.

Dan tadaaaa.. jadi deh

Tadaaaaaaaa...

Yah sekian saja, sekarang tak ada janji untuk buat tutorial lagi . See ya..

Refactor Nama

Pernahkah anda membuat sebuah field atau class pada suatu source, dan tiba-tiba di tengah perjalanan setelahnya ingin anda ganti namanya? Dan anda malas untuk menggantinya satu-satu di tempat lain yang mengaksesnya? Atau anda ingin mengganti nama sebuah fungsi yang sudah dipakai dimana-mana? Santai saja kawan karena di Eclipse anda hanya perlu menekan shortcut alt+shift+R!   Setelah memencet Enter, akan ada sebuah proses yang merubah semua source yang menggunakan nama tadi.

Misalkan kita ingin merubah nama Kelas Mazer menjadi MazerChange.

1. Caranya cukup letakkan kursor di nama yang ingin di ubah,

2. kemudian ketik shortcut alt+shift+R.

3. Ubah namanya.

4. Setelah anda merubah namanya jangan lupa ketik Enter, wajib, kalau tidak tanggung sendiri akibatnya. Hehe. Simpel dan cepat!

Banyak teknik refactor lain dalam Eclipse (sampai memindahkan suatu method), anda cukup menekan shortcut alt+shift+T, atau mengakses menu refactor pada menu atas.

Tilip selanjutnya : Teknik Source.