Web Engineering 2010 Pertemuan ke-02 Rekayasa Kebutuhan Aplikasi Web

1. Web Engineering 2010Pertemuan ke-02Rekayasa Kebutuhan Aplikasi Web Husni husni@if.trunojoyo.ac.id Husni.trunojoyo.ac.id Komputasi.wordpress.com

2. 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

3. 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.

4. 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.

5. 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

6. Dari mana Kebutuhan Hadir? • Stakeholder: orang atau organisasi yang mempunyai pengaruh langsung atau tak-langsung pada kebutuhan dalam pengembangan sistem (pelanggan, pengguna dan pengembang). • Stakeholder bagi aplikasi web termasuk penulis content, pakar bidang terkait, pakar usability atau profesional pemasaran.

7. 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.

8. Definisi Kebutuhan (IEEE) • Kondisi atau kemampuan yang dibutuhkan oleh pengguna untuk memecahkan masalah atau mencapai suatu tujuan. • Kondisi atau kemampuan yang harusdipenuhi atau diproses oleh sistem atau komponen sistem untuk memenuhi suatu kontrak, standard, spefisikasi atau dokumen yang ditentukan secara formal lainnya. • Representasi dari kondisi atau kemampuansebagaimana dalam (1) atau (2). Terdokumentasi.

9. Dokumen Kebutuhan (IEEE) • Merangkumsemua kebutuhandan batasanyang disetujuiantara pengembang dan pelanggan.

10. 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

11. Pengumpulan & Negosiasi • “ Kebutuhan tidak terkoleksi dengan mengajukan pertanyaan yang benar”. Kebutuhan merupakan hasil dari prosespembelajaran dan pembangunan kesepakatan. • Dalam proses ini, komunikasi antar stakeholdersmerupakan hal yang sangat penting.

12. 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 informalseperti cerita pengguna dan deskripsi semi-formal seperti use case, adalah sangat relevan dalam Web engineering.

13. 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, inspectionatau prototyping.

14. 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.

15. 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. RE Dalam Web Eng.

16. Tantangan RE Web Engineering • 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.

17. Tantangan RE Web Engineering • 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.

18. Tantangan RE Web Engineering • 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.

19. Tantangan RE Web Engineering • Lingkungan Operasional Sulit Diprediksi • Lingkungan operasional dari aplikasi web sangat dinamis. Sulit diprediksi. • Pengembang sulitatau tak mungkin mengendalikan faktor-faktor penting yang menentukan kualitas apliksi web yang dipersepsikan pengguna.

20. 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 webmenghadapi tantangan untuk mengintegrasikan sistem warisan.

21. Kelemahan Waterfall • Pengembang TIDAK DAPAT menggunakan pendekatan waterfalluntuk 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 modelarsitektural dari sistem ke depan. • Komponen, layanan dan infrastruktur yang ada mendefinisikan rentang peluang dan batasan bagi pengembang.

22. Kelemahan Waterfall ARTINYA: • Saat mengidentifikasi dan mendefinisikan kebutuhan, pengembang webharus menyadari arsitektur sistem dan batasan-batasannya. • Pendekatan iteratifdiajukan dalam model Twin Peaks

23. 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

24. Tantangan RE Web Engineering • 6. Pentingnya Aspek Kualitas • Aspek kualitas menentukan suksesnya aplikasi web (kinerja, keamanan, availabilityatau 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?).

25. Tantangan RE Web Engineering • 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.

26. 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.

27. 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.

28. 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.

29. Tantangan RE Web Engineering • 10 . Tanggal Delivery Perusahaan • Banyak proyek web bersifat proyek design-to-schedule, dimana semua aktifitas dan keputusan harus memenuhi suatu deadline proyek yang telah ditetapkan. • Negosiasi dan penentuan prioritas menjadi sangat krusial pada keadaan demikian.

30. 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-orientedmerupakan 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.

31. Asas RE Aplikasi Web • Memahami Konteks Sistem • Banyak aplikasi web dikembangkan sebagai solusiteknisterisolasi, tanpa memahami peran dan pengaruhnya dalam konteks lebih besar. • Aplikasi web sering tidak menjadi dirinya sendiri. Dia harus mendukung tujuan bisnis pelanggan

32. 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.

33. 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.

34. Masalah Proyek • Manajer proyek harus menghindari hadirnya individu yang mengeruk keuntungan atas yang lain. • Situasi win-loseini dapat berkembang menjadi lose-lose: Proyek keseluruhan rugi atau gagal. • Sasaran hasil (objectives), harapan (expectation) dan kebutuhan stakeholdersharus diperoleh dan dinegosiasikan berulangkali untuk mengantisipasi kebutuhan dinamis dalam proyek. • Multidisciplinarydan ketiadaan dari stakeholders merupakan tantangan RE bagi Web engineering.

35. Karena itu, Lakukan: • Identifikasi success-effective stakeholders atau perwakilan yang sesuai (dalam hal unavailability). • Memahami obyektif dan harapan dari stakeholder. • Negosiasikan harapan, pengalaman dan pengetahuan (multidisciplinarity) berbeda.

36. Metode & Tools RE • Haruskonsisten 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.

37. Asas RE Aplikasi Web • 3. Definisi Iteratif dari Kebutuhan • Pendekatan waterfalluntuk 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.

38. Kebutuhan Awal • Mengembangkan arsitektur yang mungkin, • Skenario pemanfaatan sistem kunci, • 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.

39. 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.

40. 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.

41. 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.

42. Adaptasi Metode RE ke dalam Pengembangan Aplikasi Web Tipe kebutuhan mana yang penting bagi aplikasi web? Bagaimana kebutuhan aplikasi web akan dideskripsikan & didokumentasikan? Sejauh apa manfaat dari detail & formalitas? 3. Mempertimbangkan penggunaan tool? Tool mana yang cocok bagi kebutuhan proyek?

43. 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”.

44. Tipe Kebutuhan Relevan dengan Proyek Pengembangan Web • Kebutuhan Fungsional • Kebutuhan Content • Kebutuhan Kualitas • Kebutuhan Lingkungan Sistem • Kebutuhan Evolusi

45. Kebutuhan Fungsional • Menentukan kemampuan dan layanan yang ditawarkan oleh sistem • Digambarkan menggunakan skenario use case dan spesifikasi berformat

46. Kebutuhan Konten • Menentukan konten (isi) yang akan ditampilkan (diwakili) oleh aplikasi web. • Di gambarkan dalam bentuk glossary (daftar kata).

47. Kebutuhan Kualitas Menggambarkan tingkat kualitas dari layanan dan kemampuan. Menentukan properti-properti sistem yang penting seperti keamanan, kinerja dan usability.

48. 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

49. 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

50. Kebutuhan Lingkungan Sistem • Menggambarkan bagaimana aplikasi Web dilekatkan ke dalam lingkungan target • Bagaimana aplikasi web tersebut berinteraksi dengan komponen-komponen eksternal, termasuksistem warisan, komponen komersial atau hardware khusus.