REKAYASA KEBUTUHAN APLIKASI WEB
- 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
A. 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.
- 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.
- 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.
- Stakholder: orang atau organisasi yang 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.
- 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.
- Kondisi atau kemampuan yang dibutuhkan oleh pengguna untuk memecahkan masalah atau mencapai suatu tujuan.
- 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.
- Representasi dari kondisi atau kemampuan sebagaimana dalam (1) atau (2). Terdokumentasi.
Merangkum semua kebutuhan dan batasan yang disetujui antara pengembang dan pelanggan.
G. 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
H. PENGUMPULAN DAN NEGOISASI- “ 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.
- 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.
- 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.
- 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.
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.
- Multidisciplinary
Pengembanga aplikasi web melibatkan pakar dari berbagai bidang. Misal: Pakar multimedia, pembuat content, software architecs, pakar usability, ahli database. - Tiadanya Stakeholder
Banyak stakeholders, seperti pengguna web yang potensial, masih tidak diketahui selama aktifitas RE. - Mengembangnya kebutuhan dan batasan
Kebutuhan dan batasan (misal property dari deployment platforms atau protokol komunikasi) mudah di definisikan pada software konvensional. Aplikasi web tidak. - Lingkungan operasional sulit diprediksi
Lingkungan operasional dari aplikasi web sangat dinamis. Sulit diprediksi. - Pengaruh sistem warisan
Pengembangan aplikasi web dicirikan dengan integrasi berbagai software yang telah ada, baik closed maupun open source - Pentingnya aspek kualitas
Aspek kualitas menentukan suksesnya aplikasi web (kinerja, keamanan, availability atau usability). - Kualitas user interface
User interface sangat penting untuk melengkapi definisi dan deskripsi dari kebutuhan. - Kualitas content
Content web merupakan aspek sangat penting dari aplikasi web. - Kurangnya pengalaman pengembang
Kurangnya pengalaman memanfaatkan tool pengembagan, standard, bahasa, dll dari teknologi ini dapat menyebabkan kesalahan dalam memperkirakan kejadian dan biaya menerapkan kebutuhan. - Tanggal delivery perusahaan
Banyak proyek web bersifat proyek design-to-scedhule, dimana semua aktifitas dan keputusan harus memenuhi suatu deadline proyek yang telah di tetapkan.
- Memahami konteks sistem
Banyak aplikasi web dikembangkan sebagai solusi teknis terisolasi, tanpa memahami peran dan pengaruhnya dalam konteks besar. - Melibatkan stakeholder
Success-critical stakeholders atau perwaliannya ada pada inti (heart) dari RE. - Definisi iteratif dari kebutuhan
Pendekatan waterfall untuk mendefiniskan kebutuhan biasanya tidak bekerja pada lingkungan yang sangat dinamis. - Fokus pada arsitektur sistem
Memahami arsitektur sistem memudahkan pengembang mengetahui pengaruh dari solusi yang hadir pada kebutuhan dan memperkirakan pengerjaannya. - Orientasi resiko
Poin penting munculnya resiko:- Integrasi dari komponen yang telah ada (existing) ke dalam aplikasi web
- Prediksi dari aspek kualitas sistem, atau kurang berlengalamannya pengembang.
- 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 berat.
- 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”.
- Kebutuhan fungsional
- Kebutuhan content
- Kebutuhan kualitas
- Kebutuhan lingkungan sistem
- Kebutuhan evolusi
- Fungsionality (kemampuan)
Menggambarkan kehadiran fungsi yang memenuhi properti yang didefinisikan - Reliability (handal)
Menggambarkan kemampuan produk software untuk memelihara tingkat kinerjanya - Usability
Menggambarkan upaya yang diperlukan untuk menggunakan suatu produk software - Efficiency
Menggambarkan rasio antara tingkat kinerja dari produk software dan sumberdayanya - Maintainability
Menggambarkan upaya yang dibutuhkan untuk mengimplementasikan perubahan terantisipasi dalam produk software - Portability
Menggambarkan kesesuaian produk software untuk dipindahkan dari satu lingkungan ke lingkungan lain
0 komentar:
Posting Komentar