Requirements Engineering for Web Application

Rekayasa Kebutuhan untuk Aplikasi Web

Rekayasa kebutuhan akan berdampak pada keberhasilan rekayasa web. Kebutuhan yang tidak lengkap akan menyebabkan kesulitan dalam membangun proyek web. Rekayasa web berkaitan dengan prinsip – prinsip, metode dan alat untuk memunculkan, menjelaskan, validasi dan kebutuhan pengelolaan. Dalam rekayasa web harus mengatasi kebutuhan yang tidak terduga karena pengaruh dari kegunaan dan kinerja dari web. Maka harus melakukan identifikasi yang berulang terhadap kebutuhan dan arsitektur sistem serta orientasi resiko.

Introduction

Kebutuhan itu mempunyai peranan penting dalam pengembangan aplikasi web, kebutuhan yang tidak dijelaskan dengan baik akan menimbulkan konsekuensi sistem yang rendah bahkan kegagalan arsitektur software yang tidak memadai. Rekayasa web berkaitan dengan prinsip, metode, dan alat untuk mengidentifikasi, mendesripsikan, memvalidasi dan mengelola kebutuhan dalam pengembangan sistem. Aplikasi web saat ini membutuhkan pendekatan yang sistematis maka proses kematangan rekayasa web ini sangat penting. Kebutuhan untuk pengembangan sistem yang sukses bertahun – tahun berbagai standar, pendekatan, model, deskripsi bahasa, dan alat – alat yang muncul maka industri perangkat lunak masih terus mengembangkan untuk kebutuhan mendatang.

Rekayasa web untuk memenuhi tujuan, jadwal, anggaran dan kualitas untuk pengembangan aplikasi web maka kebutuhan yang demikian sering di dokumentasikan dan dikelola dengan cara yang sistematis.

Fundamentals

Where do requirements come here

Tujuan dari proses kebutuhan agar sesuai dengan harapan pelanggan, pengguna, dan pengembang.

Tujuan dan harapan cukup beragam diantaranya :

  1. Aplikasi web harus tersedia secara online.
  2. Aplikasi web mendukung minimal 2500 pengguna secara bersama.
  3. J2EE digunakan sebagai platform pengembangan.
  4. Semua data pelanggan harus disampaikan.
  5. User interface mendukung layout untuk kelompok pelanggan yang berbeda.
  6. Seorang pengguna akan dapat menemukan produk yang diinginkan dalam waktu kurang dari 3 menit.
  7. Seorang pengguna dapat memilih ikon untuk menampilkan artikel.

Keberhasilan merupakan manajemen proyek yang penting maka membuat kebutuhan dasar yang lebih rinci serta menurunkannya. Sebuah kebutuhan menggambarkan properti yang harus dipenuhi atau disediakan. IEEE 610,12 mendefinisikan kebutuhan sebagai suatu kondisi atau kemampuan yang dibutuhkan oleh pengguna untuk memecahkan masalah atau mencapai tujuan, kondisi atau kemampuan yang harus dipenuhi atau dimiliki oleh sistem atau komponen sistem untuk memenuhi kontrak, standar, spesifikasi, atau dokumen resmi lainnya yang dikenakan. Kebutuhan biasanya dikategorikan sebagai kebutuhan fungsional, kebutuhan non-fungsional, dan kendala (Robertson dan Robertson 1999). Kebutuhan fungsional menentukan kemampuan suatu sistem dan layanan, sementara non-fungsional kebutuhan menggambarkan tingkat kualitas yang diinginkan. Metode RE demikian sering digunakan dalam konteks berulang dan pendekatan kehidupan tangkas. RE saat mendekati sehingga menekankan identifikasi dan keterlibatan pemangku kepentingan, negosiasi dan skenario berbasis penemuan kebutuhan, analisis konteks organisasi dan sosial sebelum pemodelan rinci, dan definisi yang jelas tentang kendala yang mempengaruhi perkembangan (Boehm 2000b, Nuseibeh dan Easterbrook 2000).

Requirements Engineering Activities

RE meliputi elisitasi, dokumentasi, verifikasi danvalidasi, serta pengelolaan kebutuhan seluruh proses pembangunan.

Requirements Elicitation and Negotiation

Kebutuhan adalah hasil dari proses pembelajaran dan pembangunan konsensus (Boehm etal 2001,. Lowedan Eklund 2002).

Komunikasi antara para pemangku kepentingan sangat penting, karena hanya keahlian bersama mereka dapat menyebabkan solusi yang dapat diterima bersama. Satu set macam metode dan alat kolaboratif yang tersedia untuk memfasilitasi komunikasi dan pertukaran pengetahuan di RE. Contoh termasuk teknik kreativitas, skenario berbasis metode, proses keputusan multikriteria, teknikfasilitasi, wawancara, atau analisis dokumen (Nuseibeh dan Easter brook 2000).

Requirements Documentation

Kesepakatan harus disempurnakan dan dijelaskan dalam dokumen kebutuhan ditingkat detail dan formalitas yang sesuai untuk proyek konteks. Deskripsi informal seperti cerita pengguna, dan semi formal deskripsi seperti kasus penggunaan, sangat relevan dalam rekayasa web.

Requirements Verification and Validation

Ada beberapa metode konvensional untuk tujuan ini, seperti ulasan, inspeksi, atau prototyping (Halling etal. 2003). Dalam rekayasa Web, keterbukaan Internet memfasilitasi bentuk-bentuk baru dari partisipasi pengguna langsung dalam validasi kebutuhan, misalnya, melalui koleksi online dari umpan balik pengguna (Deshpande etal. 2002).

Requirements Management

Perubahan terus menerus tentang kebutuhan dan kendala adalah karakteristik utama dari proyek Web. Metode dan alat untuk dukungan manajemen kebutuhan baik integrasi kebutuhan baru dan perubahan kebutuhan yang ada. Mereka juga membantu dalam mengevaluasi dampak dari perubahan dengan mengelola saling ketergantungan di antara kebutuhan, dan antara kebutuhan dan artefak pembangunan lainnya (traceability).

RE Specifics in Web Engineering

Perbedaan tampaknya diabaikan sebagaimana didalilkan oleh para peneliti di lapangan meskipun ada banyak perbedaan antara pengembangan Web dan pengembangan perangkat lunak ada juga kesamaan di antaranya termasuk kebutuhan elisitasi.

Multidisciplinarity

Pengembangan aplikasi Web memerlukan partisipasi para ahli dari berbagai disiplin ilmu. Contoh termasuk ahli multimedia, penulis konten, arsitek software, ahli kegunaan, spesialis database, atau ahli domain.

Unavailability of Stakeholders

Manajemen proyek perlu mencari perwakilan yang cocok yang dapat memberikan kebutuhan yang realistis. Misalnya, sering ada spektrum yang luas dari pengguna mungkin dalam proyek web dan menemukan satu set yang wajar dari perwakilan sulit.

Volatility of Requirements and Constraints

Web aplikasi dan lingkungan mereka sangat dinamis dan kebutuhan dan kendala yang biasanya sulit untuk menstabilkan. Contoh Sering perubahan teknologi inovasi seperti pengenalan platform pengembangan baru dan standar, atau perangkat baru bagi pengguna akhir.

Unpredictable Operational Environment

Pengembang merasa sulit atau tidak mungkin untuk mengontrol faktor-faktor penting yang menentukan bagi kualitas user perceived dari aplikasi Web. Misalnya, bandwidth perubahan mempengaruhi waktu respon dari aplikasi mobile, tetapi berada di luar lingkup tim pengembangan (Finkelstein danSavigni2001).

Impact of Legacy Systems

Pengembangan aplikasi Web ditandai dengan integrasi perangkat lunak yang ada komponen seperti komersial off-the-shelf produk atau perangkat lunak open source.

Dalam keadaan seperti pendekatan air terjun untuk mendapatkan arsitektur sistem dari kebutuhan tidak akan berhasil, sebagai komponen yang ada, jasa, dan infrastruktur yang menentukan berbagai kemungkinan dan keterbatasan untuk pengembang. Ini berarti bahwa, ketika mengidentifikasi dan mendefinisikan kebutuhan, pengembang web harus menyadari dari arsitektur sistem dan kendala arsitektur. Pendekatan iteratif seperti yang diusulkan dalam model Twin Peaks.

Figure 2-1 The Twin-Peaks model (Nuseibeh 2001).

Significance of Quality Aspects

Meskipun pentingnya aspek kualitas, pengembang harus berurusan dengan masalah bahwa spesifikasi yang tepat dari kebutuhan mutu seringkali sulit atau bahkan sia-sia sebelum sistem sebenarnya dibangun. Sebagai contoh, waktu respon dari aplikasi Web tergantung pada banyak faktor yang berada di luar kendali dari tim pengembangan.

Quality of the User Interface

Kualitas dari user interface adalah aspek lain keberhasilan-kritis aplikasi Web. Ketika aplikasi Web berkembang pengembang perlu menyadari fenomena (I Know It Ketika saya See It) IKIWISI: pengguna tidak akan dapat memahami dan mengevaluasi aplikasi Web dengan hanya melihat model abstrak dan spesifikasi, melainkan mereka perlu bereksperimen dengan itu.

Quality of Content

Dalam konteks RE, maka sangat penting untuk menentukan kualitas yang dibutuhkan dari konten. Karakteristik kualitas yang penting meliputi akurasi, objektivitas, kredibilitas, relevansi, aktualitas, kelengkapan, atau kejelasan (Strong et al. 1997). Sistem manajemen konten (CMS) pentingnya keuntungan dan memungkinkan mewakili konten ringkas dan konsisten dengan memisahkan konten dari tata letak, dan menawarkan alat editing konten.

Developer Inexperience

Pengalaman dengan alat pengembangan teknologi, standar, bahasa, dll dapat menyebabkan perkiraan yang salah saat menilai kelayakan dan biaya pelaksanaan kebutuhan.

Firm Delivery Dates

Principles for RE of Web Applications

RE untuk aplikasi Web harus berurusan dengan risiko dan ketidakpastian seperti volatilitas kebutuhan dan kendala, pengalaman dari para pengembang, atau dampak dari solusi warisan. Pendekatan risiko berorientasi adalah pilihan yang baik untuk menghadapi tantangan ini. Dalam bagian ini kami akan menjelaskan prinsip-prinsip dasar untuk RE aplikasi Web. Kami memperoleh prinsip-prinsip dari invariants dari model spiral (Boehm 1996,Boehm2000a), risiko-oriented dan iteratif Model siklus hidup yang menempatkan penekanan khusus pada keterlibatan para pemangku kepentingan dan elisitasi dan rekonsiliasi kebutuhan.

Understanding the System Context

Banyak aplikasi Web masih dikembangkan sebagai solusi teknis terisolasi, tanpa memahami peran mereka dan dampak dalam aplikasi context.A Web lebih besar namun bisa tidak pernah menjadi tujuan itu. Pengembang harus memahami bagaimana sistem tertanam dilingkungannya. Analisis bisnis dapat menentukan nilai dari aplikasi Web dalam kaitannya dengan sumber daya yang menggunakan kebutuhan nilai driven (Boehm 2000b).

Involving the Stakeholders

Tujuan, harapan, dan kebutuhan pemangku kepentingan harus diperoleh dan dinegosiasikan berulang kali untuk mengatasi kebutuhan yang berubah secara dinamis dalam proyek. Kami telah menunjukkan bahwa multidisciplinarity dan tidak tersedianya pemangku kepentingan spesifik RE untuk rekayasa Web. Karakteristik ini membawa kita untuk menurunkan kebutuhan berikut untuk konteks aplikasi Web : (1) identifikasi keberhasilan-efektif stakeholder atau perwakilan yang sesuai (dalam kasus tidak tersedianya), (2) pemahaman tentang tujuan stakeholder dan harapan, dan (3) negosiasi dari harapan yang berbeda, pengalaman, dan pengetahuan (multidisciplinarity).

Iterative Definition of Requirements

Kebutuhan harus konsisten dengan lainnya penting hasil pembangunan (arsitektur, antarmuka pengguna, konten, uji kasus, dll). Pada awal proyek, kebutuhan utama biasanya didefinisikan pada tingkat yang lebih tinggi dari abstraksi. Kebutuhan ini awal dapat digunakan untuk mengembangkan arsitektur layak, skenario penggunaan sistem kunci, dan rencana proyek awal. Sebagai proyek berlangsung, hasil-hasil pembangunan dapat secara bertahap disempurnakan secara lebih konkret, sementara terus memastikan konsistensi mereka.

Focusing on the System Architecture

The Twin Peaks-model (Nuseibeh 2001) menyarankan untuk memperbaiki secara bersamaan baik kebutuhan dan arsitektur sistem secara iteratif dengan tingkat terus meningkat detail. Masalah terdeteksi, masalah yang belum terpecahkan, dan konflik di antara kebutuhan merupakan risiko proyek besar. Item resiko yang khas adalah integrasi komponen yang ada ke dalam aplikasi Web, prediksi aspek sistem mutu, atau pengalaman pengembang. Sebuah penilaian risiko karena itu harus dilakukan untuk semua kebutuhan. Risiko yang teridentifikasi harus ditangani sesuai selama proyek untuk memastikan bahwa alternatif sistem berisiko tidak dikejar. Mitigasi risiko harus dilakukan sedini mungkin. Hal ini dapat mencakup, misalnya, prototyping, untuk menghindari masalah IKIWISI, rilis awal dari aplikasi web untuk mengumpulkan umpan balik pengguna, atau penggabungan awal komponen eksternal untuk menghindari masalah integrasi akhir dan parah.

Adapting RE Methods to Web Application Development

Prinsip – prinsip yang diuraikan dalam memandu definisi pendekatan proyek – spesifik RE untuk rekayasa Web. Antara lain, pengembang harus memperjelas aspek-aspek berikut selama proses adaptasi :

Yang jenis kebutuhan penting untuk aplikasi Web ?

Bagaimana kebutuhan untuk aplikasi Web dijelaskan dan didokumentasikan ?

Apa derajat berguna detail dan formalitas ?

Haruskah penggunaan alat dipertimbangkan ?

Yang alat yang cocok untuk kebutuhan proyek tertentu?

Requirement Types

Taksonomi Kebanyakan membedakan antara kebutuhan fungsional dan non-fungsional kebutuhan. Kebutuhan fungsional menggambarkan kemampuan suatu sistem dan layanan (misalnya, “Pengguna dapat memilih ikon untuk melihat artikel di keranjang belanja pada waktu tertentu.”). Non-fungsional kebutuhan menggambarkan sifat kemampuan dan tingkat yang diinginkan dari layanan (misalnya, “The aplikasi Web harus mendukung setidaknya 2500 pengguna bersamaan.”). Non-fungsional kebutuhan mengacu pada kendala proyek dan antarmuka sistem.

Functional Requirements

Kebutuhan fungsional menentukan kemampuan dan layanan sistem yang seharusnya untuk menawarkan (misalnya, transfer uang dalam aplikasi perbankan online).

Contents Requirements

Isi kebutuhan menentukan isi aplikasi Web harus mewakili. Isi dapat dijelaskan, misalnya, dalam bentuk sebuah daftar (lihat juga Bab3).

Quality Requirements

Internasional ISO / IEC standar 9126 mendefinisikan model teknologi-independen untuk kualitas perangkat lunak yang mendefinisikan karakteristik kualitas enam, masing-masing dibagi menjadi serangkaian tertentu subcharacteristics. Keenam karakteristik kualitas adalah:

• Fungsi menggambarkan adanya fungsi yang memenuhi sifat didefinisikan. Para subcharacteristics adalah kesesuaian, keakuratan, interoperabilitas, kepatuhan, dan keamanan. Keamanan sangat penting untuk aplikasi Web.

• Keandalan menggambarkan kemampuan produk software untuk mempertahankan tingkat kinerja di bawah kondisi tertentu selama jangka waktu tertentu. Para subcharacteristics yang jatuh tempo, kesalahan toleransi, dan pemulihan.

• Usability menggambarkan upaya yang diperlukan untuk menggunakan produk perangkat lunak, dan evaluasi individu oleh sekelompok pasti atau diasumsikan pengguna. Para subcharacteristics adalah saling pengertian, learnability.

• Efisiensi menggambarkan rasio antara tingkat kinerja produk perangkat lunak dan sumber daya menggunakan dalam kondisi tertentu. Subcharacteristics meliputi perilaku waktu dan perilaku sumber daya.

• Rawatan menggambarkan upaya yang diperlukan untuk melaksanakan pra-ditentukan perubahan pada produk perangkat lunak. Subcharacteristics meliputi analyzability, berubah-ubah, stabilitas, dan testability.

• Portabilitas menggambarkan kesesuaian produk perangkat lunak untuk dipindahkan dari satu lingkungan yang lain. Para subcharacteristics meliputi kemampuan beradaptasi, installability, kesesuaian, dan replaceability. Upaya awal telah dilakukan oleh para peneliti untuk memperpanjang model dasar untuk Web-spesifik karakteristik (Olsina et al. 2002).

System Environment Requirements

Kebutuhan ini menggambarkan bagaimana aplikasi Web tertanam di lingkungan target, dan bagaimana berinteraksi dengan komponen eksternal, termasuk, misalnya, sistem warisan, commercial off-rak- komponen, atau perangkat keras khusus.

User Interface Requirements

Kebutuhan mengenai antarmuka pengguna menentukan bagaimana aplikasi web berinteraksi dengan berbagai jenis kelas pengguna. Aspek-aspek penting adalah hypertext (struktur navigasi) dan presentasi (user interface). Sementara navigasi dan presentasi detail biasanya didefinisikan dalam proses pemodelan, keputusan awal tentang strategi antarmuka pengguna harus didefinisikan selama elisitasi kebutuhan. Prototip yang paling cocok untuk menghindari masalah IKIWISI. Konstantinus dan Lockwood menunjukkan bahwa pengguna harus bekerjasama dalam desain skenario untuk tugas-tugas tertentu.

Evolution Requirements

Pengembang Web perlu untuk menangkap kebutuhan yang melampaui penggunaan jangka pendek direncanakan aplikasi. Misalnya, kebutuhan kualitas menuntut 5000 pengguna tambahan bersamaan dalam dua tahun harus dipertimbangkan dengan mendefinisikan sebuah arsitektur sistem scalable.

Project Constraints

Kendala proyek tidak bisa ditawar bagi para pemangku kepentingan proyek dan biasanya mencakup anggaran dan jadwal, keterbatasan teknis, standar, pengembangan teknologi diamanatkan, aturan penyebaran,aspek pemeliharaan, kendala operasional, hukum, atau aspek budaya yang mempengaruhi proyek.

Notations

Berbagai besar notasi yang tersedia untuk menentukan kebutuhan dalam derajat yang berbeda dari detail dan formalitas. Contoh termasuk cerita, spesifikasi diformat, atau spesifikasi formal. Risiko proyek yang diidentifikasi memberikan pengarahan dalam pemilihan tingkat yang cocok kualitas spesifikasi, yaitu, untuk menentukan berapa banyak RE cukup dalam proyek tertentu.

Stories

Cerita deskripsi sehari-hari dari sifat yang diinginkan, mereka digunakan untuk menghasilkan umum pemahaman antara pelanggan dan pengembang.

Itemized Requirements

Kebutuhan terperinci adalah spesifikasi sederhana dalam bahasa alami. Kebutuhan masing-masing memiliki unik identifier. Salah satu contoh yang baik adalah item data keterangan sebagaimana dimaksud dalam IEEE/EIA-J STD-016.

Formatted Specifications

Atribut penting adalah deskripsi, prioritas, rasional, dan sejarah versi. Setiap kebutuhan diidentifikasi secara individual dan dapat direferensikan selama prosespada waktu tertentu dengan menggunakan id yang unik. Saling ketergantungan dengan kebutuhan lainnya dan hasil pembangunan lainnya, seperti dokumen arsitektur atau rencana, ditangkap untuk mendukung ketertelusuran. Kasus UML use sangat berguna untuk menggambarkan kasus requirements. Ause fungsional menggambarkan fungsi sistem dari perspektif faktor dan mengarah ke hasil yang dipahami bagi aktor. Aktor adalah suatu perusahaan eksternal untuk sistem yang berinteraksi dengan sistem. Sebuah diagram use case merupakan hubungan antara kasus penggunaan dan aktor.

Formal Specifications

Spesifikasi resmi ditulis dalam bahasa yang menggunakan sintaks yang ditetapkan secara formal dan semantik. Spesifikasi formal sangat jarang digunakan untuk menentukan aplikasi Web.

Suitability

Membandingkan notasi yang berbeda berkaitan dengan atribut akurasi, mudah validasi, efektivitas biaya, kesesuaian untuk non-ahli, dan skalabilitas rendah untuk akurasi menengahakan cukup untuk menentukan kebutuhan aplikasi Web dan validasi resmi biasanya tidak diperlukan. Hal ini biasanya penting untuk menjaga upaya untuk memunculkan dan mengelola kebutuhan yang rendah, dan kebutuhan harus dimengerti untuk non-ahli.

Tools

RE alat yang ada tidak terbatas pada aplikasi Web, tetapi dapat disesuaikan dengan spesifikasi pengembangan aplikasi Web.

Requirements Elicitation

Pendekatan groupware-didukung yang memandu tim stakeholder dalam upaya mereka untuk bersama-sama mendapatkan dan menegosiasikan kebutuhan. EasyWinWin mendefinisikan serangkaian kegiatan dari proses negosiasi. Sebuah panduan moderator stakeholder melalui proses. Pendekatan ini menggunakan teknik fasilitasi kelompok yang didukung oleh alat-alat kolaboratif (electronic brainstorming, mengkategorikan, pemungutan suara, dll).

Requirements Validation

Karena keterbukaan internet, sistem umpan balik online dapat melengkapi atau bahkan menggantikan metode yang lebih mahal, seperti pertemuan pribadi atau wawancara, ketika memvalidasi kebutuhan aplikasi Web. Sebagai contoh, pengguna internet dapat diundang untuk berpartisipasi dalam survei web untuk berkomunikasi kepuasan mereka dengan aplikasi Web.

Requirements Management

Kebutuhan alat manajemen memungkinkan mengelola semua kebutuhan dikumpulkan dalam sebuah proyek dalam pusat repositori. Berbeda dengan sistem pengolah kata, alat manajemen kebutuhan menyimpan kebutuhan dalam database. Kebutuhan sistem manajemen adalah penting untuk manajemen perubahan dan mampu telusur kebutuhan. Sebuah gambaran yang baik dari alat yang ada dapat ditemukan di (http://www.paper-review.com/tools/rms/read.php).

Outlook

Tren perkembangan beberapa di RE untuk aplikasi web di bawah ini :

• Menghilang perbatasan antara pengembangan dan penggunaan sistem : aplikasi Web dapat

dibuat tersedia untuk pengguna selama pengembangan, dan kemudian dapat berkembang ketika mereka sudah sedang digunakan. Pemisahan yang ketat dari pengembangan sistem dan penggunaan sistem yang sangat umum dalam sistem konvensional akan menjadi kurang relevan di masa depan.

• Lebih baik integrasi kebutuhan dan arsitektur: Para peneliti telah mengembangkan pendekatan awal untuk pemodelan hubungan yang kompleks dan saling ketergantungan antara kebutuhan, komponen dan properti dari arsitektur sistem (Gr ¨ unbacher et al 2001,.Franch dan Maiden 2003). Di masa depan, kami sangat membutuhkan cara yang lebih baik untuk model non-fungsional kebutuhan dan kendala sejak dini.

• Baru alat untuk rekayasa kebutuhan terdistribusi: Kemungkinan Internet dan bentuk-bentuk kerjasama internasional yang baru dalam perdagangan dan industri berarti bahwa kebutuhan semakin akan ditentukan oleh geografis dan tim didistribusikan tepat waktu (Gr ¨ unbacher dan Braunsberger 2003), menyebabkan perubahan lebih lanjut dalam proses RE. Alat-alat inovatif untuk mendukung para pemangku kepentingan akan didistribusikan harus dikembangkan untuk tugas ini.

• RE dalam sistem terbuka: tantangan baru juga berasal dari keterbukaan internet. Aplikasi Web terdiri dari berbagai komponen (misalnya, layanan Web), yang dirancang, dikembangkan, dan dioperasikan oleh kelompok pemangku kepentingan yang berbeda. Kelompok-kelompok pemangku kepentingan dapat mengejar tujuan-tujuan yang berbeda atau berubah dalam operasi mereka dan penggunaan aplikasi Web, yang berarti bahwa perilaku keseluruhan akan sulit untuk memprediksi.

 

 

 

Tinggalkan Balasan

Isikan data di bawah atau klik salah satu ikon untuk log in:

Logo WordPress.com

You are commenting using your WordPress.com account. Logout / Ubah )

Gambar Twitter

You are commenting using your Twitter account. Logout / Ubah )

Foto Facebook

You are commenting using your Facebook account. Logout / Ubah )

Foto Google+

You are commenting using your Google+ account. Logout / Ubah )

Connecting to %s