Rekayasa Kebutuhan Aplikasi Web

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

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.

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.

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

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.

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.

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.

Dokumen Kebutuhan (IEEE)

•

Merangkum

semua

kebutuhan

dan

batasan

yang

disetujui

antara pengembang dan pelanggan.

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

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.

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,

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.

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.

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.

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.

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.

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.

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.

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.

Kelemahan Waterfall

ARTINYA:

• Saat mengidentifikasi dan mendefinisikan kebutuhan, pengembang web harus

menyadari arsitektur sistem dan batasan-batasannya.

• Pendekatan iteratif diajukan dalam model Twin Peaks

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

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

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

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.

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.

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

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.

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

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

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.

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.

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

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.

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.

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.

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.

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.

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.

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

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

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

properti-properti 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 ₄₉

Kebutuhan Lingkungan Sistem

• Menggambarkan bagaimana aplikasi Web dilekatkan ke dalam lingkungan target

• Bagaimana aplikasi web tersebut

berinteraksi dengan komponen-komponen eksternal, termasuk sistem warisan,

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

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

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

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

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

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

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.