Web Engineering 2010 Rekayasa Kebutuhan Aplikasi Web Husni husni@if.trunojoyo.ac.id Husni.trunojoyo.ac.id Komputasi.wordpress.com
Outline Pendahuluan Fundamental Tantangan Rekayasa Kebutuhan (Requirement Engineering, RE) dalam Web Engineering Asas Rekayasa Kebutuhan Aplikasi Web Adaptasi Metode RE untuk Pengembangan Aplikasi Web Harapan ke Depan 2
Pendahuluan Kebutuhan atau persyaratan sistem memegang peranan kunci dalam proyek pengembangan aplikasi web. RE berurusan dengan prinsip, metode dan tool untuk mengidentifikasi, menggambarkan, memvalidasi, dan mengelola kebutuhan di dalam pengembangan sistem. 3
Fundamental Kebutuhan tidak dihasilkan secara otomatis tetapi harus diidentifikasi dalam aktifitas engineering. Terlambat memperbaiki kerusakan dapat menyebabkan kerugian s.d 200 kali dibandingkan masalah diidentifikasi dan dikoreksi sejak awal Pengumpulan dan menyaringan kebutuhan adalah fungsi utama insinyur software bagi pelanggan. 4
Fundamental Masih sedikit pengalaman dalam aplikasi web dibandingkan domain lain. Kebutuhan diperoleh, didokumentasikan dan dikelola secara sangat tidak sistematis. 16% dari aplikasi web 100% memenuhi kebutuhan, 53% tidak memenuhi kemampuan yang dibutuhkan 5
Dari mana Kebutuhan Hadir? Stakeholder: orang atau organisasi yang mempunyai pengaruh langsung atau taklangsung pada kebutuhan dalam pengembangan sistem (pelanggan, pengguna dan pengembang). Stakeholder bagi aplikasi web termasuk penulis content, pakar bidang terkait, pakar usability atau profesional pemasaran. 6
Kategori Kebutuhan Fungsional: kemampuan dan layanan yang diberikan sistem. Non-fungsional: menggambarkan tingkat kualitas yang diinginkan ( Berapa aman?, Berapa usable? ). Batasan: kondisi yang tak dapat dinegosiasikan tetapi mempengaruhi proyek. Misal: tingkat keterampilan dari tim pengembangan, anggaran yang tersedia, tanggal delivery atau infrastruktur komputer. 7
Definisi Kebutuhan (IEEE) 1. Kondisi atau kemampuan yang dibutuhkan oleh pengguna untuk memecahkan masalah atau mencapai suatu tujuan. 2. Kondisi atau kemampuan yang harus dipenuhi atau diproses oleh sistem atau komponen sistem untuk memenuhi suatu kontrak, standard, spefisikasi atau dokumen yang ditentukan secara formal lainnya. 3. Representasi dari kondisi atau kemampuan sebagaimana dalam (1) atau (2). Terdokumentasi. 8
Dokumen Kebutuhan (IEEE) Merangkum semua kebutuhan dan batasan yang disetujui antara pengembang dan pelanggan. 9
Aktifitas Rekayasa Kebutuhan Mencakup pengumpulan, dokumentasi, verifikasi dan validasi, juga manajemen dari kebutuhan sepanjang proses pengembangan. Konsekwensinya: Pengumpulan & Negosiasi Kebutuhan Dokumentasi Kebutuhan Verifikasi & Validasi Kebutuhan Manajemen Kebutuhan 10
Pengumpulan & Negosiasi Kebutuhan tidak terkoleksi dengan mengajukan pertanyaan yang benar. Kebutuhan merupakan hasil dari proses pembelajaran dan pembangunan kesepakatan. Dalam proses ini, komunikasi antar stakeholders merupakan hal yang sangat penting. 11
Dokumentasi Kebutuhan Stakeholders agreements (kesepakatan para stakeholder) harus disaring dan dideskripsikan dalam requirements document (Dokumen Kebutuhan) secara rinci (detail), formal dan tepat bagi konteks proyek. Deskripsi informal seperti cerita pengguna dan deskripsi semi-formal seperti use case, adalah sangat relevan dalam Web engineering. 12
Validasi & Verifikasi Kebutuhan perlu divalidasi (disahkan) (Apakah kita menetapkan hal-hal yang benar?) dan diverifikasi (dibuktikan) (Apakah kita menetapkan hal-hal secara benar?). Ada beberapa metode konvensional untuk tujuan ini seperti review, inspection atau prototyping. 13
Manajemen Kebutuhan Kebutuhan merupakan subyek yang sering berubah Metode dan tool untuk tujuan ini harus mendukung integrasi kebutuhan baru, perubahan kebutuhan yang ada, mengevaluasi pengaruh perubahan dan mengelola hubungan antar kebutuhan. 14
RE Dalam Web Eng. Dibandingkan software konvensional: Ada perbedaan dan kemiripan. Sekilas perbedaan terlihat tak berarti (dapat diabaikan) dan diperdebatkan. Jika dilihat lebih dekat ke beberapa pokok, perbedaannya menjadi jelas. Perbedaan akan diperoleh berdasarkan karakteristik dari aplikasi web.
Tantangan RE Web Engineering 1. Multidisciplinary Pengembangan aplikasi web melibatkan pakar dari berbagai bidang. Misal: Pakar multimedia, pembuat content, software architects, pakar usability, ahli database. Heterogenitas dan multidisiplin dari stakeholders memunculkan tantangan untuk mencapai konsensus saat mendefinisikan kebutuhan. Sulit. Orang-orang dari berbagai disiplin mempunyai bahasa dan jargon sendiri, perlu rekonsiliasi. 16
Tantangan RE Web Engineering 2. Tiadanya Stakeholder Banyak stakeholders, seperti pengguna web yang potensial, masih tidak diketahui selama aktifitas RE. Manajemen proyek harus menunjuk wakil yang tepat untuk menyediakan kebutuhan realistis. 17
Tantangan RE Web Engineering 3. Mengambangnya Kebutuhan & Batasan Kebutuhan dan batasan (misal properti dari deployment platforms atau protokol komunikasi) mudah didefinisikan pada software konvensional. Aplikasi web tidak. Aplikasi web dan lingkungannya sangat dinamis. Kebutuhan dan batasan lebih sulit untuk distabilkan. Contoh: inovasi teknologi - munculnya platform dan standard pengembangan, perangkat baru. 18
Tantangan RE Web Engineering 4.Lingkungan Operasional Sulit Diprediksi Lingkungan operasional dari aplikasi web sangat dinamis. Sulit diprediksi. Pengembang sulit atau tak mungkin mengendalikan faktor-faktor penting yang menentukan kualitas apliksi web yang dipersepsikan pengguna. 19
Tantangan RE Web Engineering 5. Pengaruh Sistem Warisan Pengembangan aplikasi web dicirikan dengan integrasi berbagai software yang telah ada, baik closed maupun open source. Pengembang web menghadapi tantangan untuk mengintegrasikan sistem warisan. 20
Kelemahan Waterfall Pengembang TIDAK DAPAT menggunakan pendekatan waterfall untuk mendapatkan arsitektur sistem dari kebutuhan, karena: Pengembang sering diminta untuk menggunakan komponen yang sudah ada karena alasan eknomis Komponen yang diperlukan untuk mengintegrasikan sangat mempengaruhi kebutuhan dan model arsitektural dari sistem ke depan. Komponen, layanan dan infrastruktur yang ada mendefinisikan rentang peluang dan batasan bagi pengembang. 21
Kelemahan Waterfall ARTINYA: Saat mengidentifikasi dan mendefinisikan kebutuhan, pengembang web harus menyadari arsitektur sistem dan batasanbatasannya. Pendekatan iteratif diajukan dalam model Twin Peaks 22
Model Twin Peaks Model pengembangan proyek e-science. Framework pengembangan kebutuhan & arsitektur berjalan semi-bebas. Tantangan: Memastikan bahwa kebutuhan dan arsitektur akan menyatu. Jelas menggambarkan solusi praktis penyelesaiannya 23
Tantangan RE Web Engineering 6. Pentingnya Aspek Kualitas Aspek kualitas menentukan suksesnya aplikasi web (kinerja, keamanan, availability atau usability.) SADARLAH. Spesifikasi tepat sulit dibuat sebelum sistem sebenarnya dibangun. Pendekatan bagus dalam mendefinisikan kebutuhan kualitas: Tetapkan kriteria TEST PENERIMAAN (Apakah suatu kebutuhan telah dipernuhi?). 24
Tantangan RE Web Engineering 7. Kualitas User Interface Aspek kritis suksesnya aplikasi web. Pengembangan sebaiknya memahami fenomena IKIWISI (I Know It When I See It). Pengguna tidak mampu memahami dan mengevaluasi aplikasi web hanya dengan melihat model abstrak dan spesifikasinya. Mereka perlu bereksperimen dengan Aplikasi tersebut. User interface sangat penting untuk melengkapi definisi dan deskripsi dari kebutuhan Tambahkan prototypes dari skenario aplikasi yang penting. 25
Tantangan RE Web Engineering 8. Kualitas Content Content web, merupakan aspek sangat penting dari aplikasi web Selain teknologi software, pengembang harus memperhitungkan content, terutama pembuatan dan perawatannya. Dalam konteks RE, sangat penting mendefinisikan kualitas content yang dibutuhkan. 26
Tantangan RE Web Engineering Kualitas penting termasuk: Accuracy (ketelitian, ketepatan) Objectivity (keobyektifan) Credibility (kepercayaan) Relevance (relevansi, keterkaitan) Actuality (aktualitas, sesuai kenyataan?) Completeness (kesempurnaan) Clarity (kejelasan) CMS memunuhi kualitas penting, menyajikan content dengan singkat dan konsisten. Memisahkan content dari layout, menawarkan tool untuk mengelola content. 27
Pokok-pokok RE Web Engineering 9. Kurangnya Pengalaman Pengembang Banyak teknologi utama dalam aplikasi web masih baru. Kurangnya pengalaman memanfaatkan tool pengembangan, standard, bahasa, dll dari teknologi ini dapat menyebabkan kesalahan dalam memperkirakankejadian dan biaya menerapkan kebutuhan. 28
Tantangan RE Web Engineering 10. Tanggal Delivery Perusahaan Banyak proyek web bersifat proyek design-toschedule, dimana semua aktifitas dan keputusan harus memenuhi suatu deadline proyek yang telah ditetapkan. Negosiasi dan penentuan prioritas menjadi sangat krusial pada keadaan demikian. 29
Asas RE Aplikasi Web RE aplikasi web berurusan dengan resiko dan ketidakpastian, seperti kebutuhan dan batasan mengambang, pengembang kurang pengalaman atau pengaruh solusi warisan. Pendekatan risk-oriented merupakan pilihan yang bagus untuk menyelesaikan dengan tantangan ini. Asas-asas turunan win-win spiral, model siklus hidup iteratif dan berorientasi resiko, menempatkan fokus khusus pada keterlibatan stakeholders, pengumpulan dan rekonsiliasi kebutuhan. 30
Asas RE Aplikasi Web 1. Memahami Konteks Sistem Banyak aplikasi web dikembangkan sebagai solusi teknis terisolasi, tanpa memahami peran dan pengaruhnya dalam konteks lebih besar. Aplikasi web sering tidak menjadi dirinya sendiri. Dia harus mendukung tujuan bisnis pelanggan 31
Asas RE Aplikasi Web Kunci Sukses Aplikasi Web, PENGEMBANG HARUS : Memahami konteks sistem (misal: menganalisis & menggambarkan proses bisnis) Rasional dari sistem yang akan dikembangkan ( Apa tujuan dari aktifitas yang dilakukan ini? ). Memahami bagaimana sistem dipasangkan ke dalam lingkungannya. Memahami konteks sistem memudahkan mengenali success-critical stakeholders, maksud atau makna yang digunakan & menganalisis batasan-batasan. 32
Asas RE Aplikasi Web 2. Melibatkan Stakeholder Success-critical stakeholders atau perwakilannya ada pada inti (heart) dari RE. Keaktifannya dan kerjasama langsung dalam mengidentifikasi dan menegosiasikan kebutuhan adalah sangat penting dalam tiap fase proyek. 33
Masalah Proyek Manajer proyek harus menghindari hadirnya individu yang mengeruk keuntungan atas yang lain. Situasi win-lose ini dapat berkembang menjadi lose-lose: Proyek keseluruhan rugi atau gagal. Sasaran hasil (objectives), harapan (expectation) dan kebutuhan stakeholders harus diperoleh dan dinegosiasikan berulangkali untuk mengantisipasi kebutuhan dinamis dalam proyek. Multidisciplinary dan ketiadaan dari stakeholders merupakan tantangan RE bagi Web engineering. 34
Karena itu, Lakukan: 1. Identifikasi success-effective stakeholders atau perwakilan yang sesuai (dalam hal unavailability). 2. Memahami obyektif dan harapan dari stakeholder. 3. Negosiasikan harapan, pengalaman dan pengetahuan (multidisciplinarity) berbeda. 35
Metode & Tools RE Harus konsisten dengan kebutuhan dan berkontribusi dalam: Pertukaran pengetahuan yang efektif antar partisipan proyek, Mendukung proses pembelajaran tim, Pengembangan visi bersama antar stakeholder, Mendeteksi kebutuhan yang konflik sejak dini. Orang mengetahui lebih banyak daripada yang diucapkan. Perlu teknik untuk memunculkan pengetahuan yang tersembunyi. 36
Asas RE Aplikasi Web 3. Definisi Iteratif dari Kebutuhan Pendekatan waterfall untuk mendefinisikan kebutuhan biasanya tidak bekerja pada lingkungan yang sangat dinamis. Kebutuhan sebaiknya diperoleh secara iteratif dalam lingkup aplikasi web. Kebutuhan harus konsisten dengan hasil pengembangan penting lain (arsitektur, user interface, content, test cases, dll). Pada permulaan proyek, kebutuhan kunci biasanya didefinisikan pada level abstraksi yang lebih tinggi. 37
Kebutuhan Awal 1. Mengembangkan arsitektur yang mungkin, 2. Skenario pemanfaatan sistem kunci, 3. Perancaaan proyek awal. Seiring kemajuan proyek, hasil pengembangan disaring secara bertahap dan lebih konkret. Konsistensinya dipastikan berkelanjutan. Perlu Pendekatan iteratif, terutama dalam lingkungan yang kebutuhan dan batasannya mudah berubah, agar mampu bereaksi fleksibel mengikuti perkembangan proyek. 38
Asas RE Aplikasi Web 4. Fokus pada Arsitektur Sistem Teknologi dan solusi warisan memiliki pengaruh pada kebutuhan aplikasi web. Ruang solusi mendefinisikan ruang masalah. Memahami elemen solusi teknis yang mungkin dan batasannya sangatlah penting. Harus masuk ketika mendefinisikan kebutuhan Memahami arsitektur sistem memudahkan pengembang mengetahui pengaruh dari solusi yang hadir pada kebutuhan dan memperkirakan pengerjaaannya. 39
Asas RE Aplikasi Web 5. Orientasi Resiko Masalah yang tak terdeteksi, isu-isu yang belum terselesaikan, dan konflik antar kebutuhan mewakili resiko proyek utama. Poin penting munculnya resiko: Integrasi dari komponen yang telah ada (existing) ke dalam aplikasi web, Prediksi dari aspek kualitas sistem, atau Kurang berpengalamannya pengembang. 40
Antisipasi Resiko Penilaian terhadap resiko dilakukan sebelum pelaksanaan kebutuhan. Resiko yang teridentifikasi disesuaikan dengan rangkaian proyek. Pastikan alternatif solusi tidak mengejar. Kelonggaran resiko harus ditempatkan sedini mungkin. Termasuk pembuatan prototipe, untuk menghindari masalah IKIWISI, rilis awal dari aplikasi web untuk mengumpulkan feedback pengguna atau penggabungan awal dari komponen eksternal untuk menghindari masalah integrasi yang terlambat dan and berat. 41
Adaptasi Metode RE ke dalam Pengembangan Aplikasi Web 1. Tipe kebutuhan mana yang penting bagi aplikasi web? 2. Bagaimana kebutuhan aplikasi web akan dideskripsikan & didokumentasikan? Sejauh apa manfaat dari detail & formalitas? 3. Mempertimbangkan penggunaan tool? Tool mana yang cocok bagi kebutuhan proyek?
Tipe Kebutuhan Kebutuhan Fungsional Kemampuan dan layanan sistem Pengguna dapat memilih suatu icon untuk menampilkan artikel dalam shopping cart pada waktu tertentu. Kebutuhan Non-Fungsional Properti dari kamampuan dan level layanan yang diharapkan Aplikasi web akan mendukung setidaknya 2500 pengguna aktif.
Tipe Kebutuhan Relevan dengan Proyek Pengembangan Web Kebutuhan Fungsional Kebutuhan Content Kebutuhan Kualitas Kebutuhan Lingkungan Sistem Kebutuhan Evolusi
Kebutuhan Fungsional Menentukan kemampuan dan layanan yang ditawarkan oleh sistem Digambarkan menggunakan skenario use case dan spesifikasi berformat
Kebutuhan Konten Menentukan konten (isi) yang akan ditampilkan (diwakili) oleh aplikasi web. Di gambarkan dalam bentuk glossary (daftar kata).
Kebutuhan Kualitas Menggambarkan tingkat kualitas dari layanan dan kemampuan. Menentukan propertiproperti sistem yang penting seperti keamanan, kinerja dan usability.
Ciri Kualitas 1. Functionality (Kemampuan) Menggambarkan kehadiran fungsi yang memenuhi properti yang didefinisikan 2. Reliability (Handal) Menggambarkan kemampuan produk software untuk memelihara tingkat kinerjanya 3. Usability Menggambarkan upaya yang diperlukan untuk menggunakan suatu produk software
Ciri Kualitas 4. Efficiency Menggambarkan rasio antara tingkat kinerja dari produk software dan sumberdayanya 5. Maintainability Menggambarkan upaya yang dibutuhkan untuk mengimplementasikan perubahan terantisipasi dalam produk software 6. Portability Menggambarkan kesesuaian produk software untuk dipindahkan dari satu lingkungan ke lingkungan lain 49
Kebutuhan Lingkungan Sistem Menggambarkan bagaimana aplikasi Web dilekatkan ke dalam lingkungan target Bagaimana aplikasi web tersebut berinteraksi dengan komponen-komponen eksternal, termasuk sistem warisan, komponen komersial atau hardware khusus.
Kebutuhan Antarmuka Pengguna Kebutuhan mengenai user interface, mendefinisikan bagaimana aplikasi web berinteraksi dengan berbagai jenis kelas penguna. Aspek yang penting adalah hypertext (struktur navigasi) dan presentasi (user interface).
Kebutuhan Evolusi Aplikasi web merupakan subyek evolusi dan perbaikan (peningkatan) yang berjalan terus menerus.
Batasan (Constraint) Proyek Termasuk Batasan : Anggaran (budget) dan penjadwalan (schedule) Teknis, standard, teknologi pengembangan Aturan penyebaran (deployment), aspek perawatan (maintenance) dan operasional Aspek legal atau budaya yang mempengaruhi suatu proyek.
Notasi Dalam Dokumen Cerita. Digunakan untuk menghasilkan pemahaman umum antara pelanggan dan pengembang Kebutuhan Itemized (Terperinci). Spesifikasi sederhana dalam bahasa alami. Setiap kebutuhan diberi pengenal yang unik Spesifikasi Berformat. Menggunakan sintaks yang terdefinisi dengan akurat, tetapi boleh menyertakan deskripsi bahasa alami seperti use case. Spesifikasi Formal. Ditulis dalam bahasa yang menggunakan sintaks dan semantic yang didefinisikan secara formal.
Harapan Ke Depan Menghilangkan batas antara pengembangan dan pemanfaatan sistem dalam aplikasi web. Integrasi kebutuhan dan arsitektur yang lebih baik (pendekatan untuk memodelkan relasi yang kompleks dan saling-tergantung antara kebutuhan, komponen dan properti-properti dari arsitektur sistem). 55
Harapan Ke Depan Tool baru untuk rekayasa kebutuhan terdistribusi (tim tersebar secara geografis tetapi proses berjalan tepat waktu). RE dalam sistem terbuka (tantangan baru, sulit memperkirakan aktifitas atau perilaku keseluruhan). 56
Pertanyaan Review Sebutkan aktifitas utama dalam Rekayasa Kebutuhan (RE)! Dari mana datangnya kebutuhan? Jelaskan 3 kategori kebutuhan, apa perbedaan utama dari ketiganya. Jelaskan definisi kebutuhan menurut IEEE. Mengapa pendekatan waterfall kurang tepat dalam mendefinisikan kebutuhan aplikasi web? Mengapa pendekatan risk-oriented merupakan pilihan terbaik? Tipe kebutuhan apa yang sangat relevan dalam proyek pengembangan Web 57
Tugas Kelompok Pastikan tim anda, 1 s.d 4 orang Diskusikan (dalam tim anda) contoh proyek aplikasi web yang akan diusulkan Diskusikan contoh proyek terpilih tersebut dengan pembimbing (dosen pengampu) Kumpulkan kebutuhan dari stakeholder. Analisis hasilnya dan dokumentasikan. Gunakan UML untuk membuat use case. 58