Requirements Engineering for Web Applications

Rekayasa Kebutuhan (RE) meliputi kegiatan yang sangat penting bagi keberhasilan rekayasa Web. Kebutuhan tidak lengkap, ambigu, atau tidak benar dapat menyebabkan kesulitan berat dalam pembangunan, atau bahkan menyebabkan pembatalan proyek. RE berkaitan dengan prinsip-prinsip, metode, dan alat untuk memunculkan, menjelaskan, validasi, dan kebutuhan pengelolaan.

 I.    Pengantar

Metode yang digunakan pada Rekayasa Kebutuhan ini sangat banyak dan juga terdapat beberapa alat yang tersedia. Namun, pendekatan ini sering tidak diterapkan oleh para praktisi dan Rekayasa Kebutuhan ini sering dilakukan secara ad-hoc, khususnya di bidang teknik Web. Meskipun kompleksitas aplikasi web saat ini membutuhkan pendekatan yang lebih sistematis, kematangan proses pada rekayasa kebutuhan sering tidak cukup. Mendefinisikan kebutuhan jelas bukan masalah baru. Ada pengembangan yang sangat luas tentang pentingnya kebutuhan untuk pengembangan sistem yang sukses dan selama bertahun-tahun berbagai standar, pendekatan, model, deskripsi bahasa, dan alat-alat telah muncul. Namun demikian, industri perangkat lunak masih mengalami kesulitan besar ketika :

  1. Dalam sebuah penelitian yang dilakukan di antara 340 perusahaan di Austria pada tahun 1995, lebih dari dua pertiga dari perusahaan-perusahaan ini dianggap mengembangan dokumen kebutuhan sebagai masalah besar dalam proses pembangunan mereka.
  2. Sebuah survei di antara lebih dari 8000 proyek yang dilakukan oleh Standish Group menunjukkan bahwa 30% dari semua proyek gagal sebelum penyelesaian dan 70% dari proyek yang tersisa tidak memenuhi harapan pelanggan.
  3. Menurut sebuah studi pada pengembangan aplikasi Web yang dilakukan oleh Konsorsium Cutter hanya 16% dari sistem sepenuhnya memenuhi kebutuhan dari kontraktor, sementara 53% dari sistem dikerahkan tidak memenuhi kemampuan yang diperlukan.

Meskipun ada konsekuen umum tentang pentingnya nilai-nilai rekayasa web untuk memenuhi jadwal, anggaran dan sasaran mutu, sering ada masalah dalam adaptasi dan penggunaan proses, metode elisitasi, notasi dan alat-alat terutama dalam pengembangan aplikasi web.

II.    Dasar

1.      Dari mana asalnya kebutuhan?

Tujuan individu dan harapan stakeholder adalah titik awal dari proses elisitasi kebutuhan. Stakeholder adalah orang-orang atau organisasi yang memiliki pengaruh langsung atau tidak langsung pada kebutuhan dalam pengembangan sistem. Stakeholder penting bagi pelanggan, pengguna, dan pengembang. Stakeholder Khas untuk aplikasi web termasuk penulis konten, ahli domain, ahli kegunaan, atau profesional pemasaran. Tujuan dan harapan stakeholder sangat beragam, seperti yang ditunjukkan oleh beberapa contoh:

  • Aplikasi web harus tersedia secara online.
  • Aplikasi web mendukung minimal 2500 pengguna secara bersama.
  • J2EE digunakan sebagai platform pengembangan.
  • Semua data pelanggan harus disampaikan.
  • User interface mendukung layout untuk kelompok pelanggan yang berbeda.
  • Seorang pengguna akan dapat menemukan produk yang diinginkan dalam waktu kurang dari 3 menit.
  • 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).

2.      Aktivitas Kebutuhan Rekayasa

Rekayasa web meliputi elisitasi, dokumentasi, verifikasi dan validasi, serta manajemen kebutuhan seluruh proses pembangunan.

  • Kebutuhan elisitasi dan Negosiasi

Para peneliti telah menunjukkan bahwa “kebutuhan tidak keluar sana untuk dikumpulkan dengan mengajukan pertanyaan yang tepat” (Nuseibeh dan Easterbrook 2000). Sebaliknya, kebutuhan adalah hasil dari proses pembelajaran dan pembangunan konsensus (Boehm et al 2001,. Lowe dan Eklund 2002).

  • Kebutuhan Dokumentasi

Jika stakeholder mencapai konsensus, kesepakatan mereka harus disempurnakan dan dijelaskan dalam dokumen kebutuhan di tingkat detail dan formalitas yang sesuai untuk proyek konteks.

  • Kebutuhan Verifikasi dan Validasi

Kebutuhan harus divalidasi (“Apakah kita tentukan hal yang benar?”) Dan diverifikasi (“Apakah kita menentukan hal-hal dengan benar “)?. Ada beberapa metode konvensional untuk tujuan ini, seperti ulasan, inspeksi, atau prototyping (Halling et al. 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 et al. 2002).

  • Kebutuhan Manajemen

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.

3.      Spesifik REdalam RekayasaWeb

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.

  • Ketidaktersediaan Stakeholder

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.

  • Volatilitas Kebutuhan dan Kendala

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.

  • Kebutuhan dan Kendala

Kebutuhan dan kendala seperti sifat dari platform penyebaran atau komunikasi protokol sering lebih mudah untuk menentukan untuk sistem perangkat lunak konvensional daripada untuk aplikasi Web. Aplikasi web dan lingkungan mereka sangat dinamis, kebutuhan dan kendala biasanya sulit untuk menstabilkan. Contoh Sering perubahan inovasi teknologi tersebut sebagai pengenalan platform pengembangan baru dan standar, atau perangkat baru bagi pengguna akhir.

  • Dampak Sistem Legacy

Pengembangan aplikasi Web ditandai dengan integrasi perangkat lunak yang ada komponen seperti komersial off-the-shelf produk atau perangkat lunak open source. Secara khusus, Pengembang web yang sering menghadapi tantangan untuk mengintegrasikan sistem warisan, misalnya ketika membuat sistem TI yang ada dari sebuah perusahaan dapat diakses melalui web Pengembang sering diminta untuk menggunakan komponen yang ada untuk alasan ekonomi.

  • Signifikansi dari Aspek Kualitas

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.

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

  • Kualitas Konten

Banyak metode tradisional mengabaikan konten Web, meskipun merupakan aspek yang sangat penting dari aplikasi Web. Selain masalah teknologi perangkat lunak, pengembang harus mempertimbangkan isi, khususnya penciptaan dan pemeliharaan. Dalam konteks RE, itu sangat penting untuk menentukan kualitas yang dibutuhkan dari konten. Karakteristik kualitas penting termasuk akurasi, objektivitas, kredibilitas, relevansi, aktualitas, kelengkapan, atau kejelasan .

  • Kurangnya pengalaman pengembangan

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

4.      Prinsip RE Aplikasi Web

Karakteristik Bagian sebelumnya membahas aplikasi Web dan spesifik RE di rekayasa Web. Kami telah menunjukkan bahwa RE untuk aplikasi Web harus berurusan dengan risiko dan ketidakpastian seperti volatilitas kebutuhan dan kendala, pengalaman dari para pengembang, atau dampak dari warisan solusi. Pendekatan risiko berorientasi adalah pilihan yang baik untuk menghadapi tantangan ini. dalam hal ini Bagian kita menggambarkan prinsip-prinsip dasar untuk RE aplikasi Web.  Pengembang web harus menjaga prinsip-prinsip berikut  ketika melakukan kegiatan RE:

  • Memahami Konteks Sistem

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

  • Melibatkan Stakeholder

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

  • Iteratif Definisi Kebutuhan

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.

  • Fokus pada Arsitektur Sistem

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.

  • Risiko Orientasi

 5.      Beradaptasi Metode RE untuk Pengembangan Aplikasi Web

Pada saat ini berbagai metode, pedoman, notasi, daftar periksa, dan alat-alat yang tersedia untuk semua kegiatan di RE. Namun, dalam rangka untuk berhasil pengembang harus menghindari “satu ukuran cocok untuk semua” Pendekatan, dan RE metode akibatnya harus disesuaikan dengan spesifikasi teknik Web dan situasi dari proyek-proyek tertentu. 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.
  • Haruskah penggunaan alat dipertimbangkan?

 

  • Jenis Kebutuhan

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.

1)      Kebutuhan Fungsional

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

2)      Kebutuhan Isi

Isi dari sebuah kebutuhan menentukan isi aplikasi Web harus mewakili. Isi dapat dijelaskan, misalnya, dalam bentuk sebuah daftar

3)      Kualitas Kebutuhan

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:

  1. Fungsi menggambarkan adanya fungsi yang memenuhi sifat didefinisikan. Para subcharacteristics adalah kesesuaian, keakuratan, interoperabilitas, kepatuhan, dan keamanan. Keamanan sangat penting untuk aplikasi Web.
  2. 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.
  3. 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.
  4. Efisiensi menggambarkan rasio antara tingkat kinerja produk perangkat lunak dan sumber daya menggunakan dalam kondisi tertentu. Subcharacteristics meliputi perilaku waktu dan perilaku sumber daya.
  5. Rawatan menggambarkan upaya yang diperlukan untuk melaksanakan pra-ditentukan perubahan pada produk perangkat lunak. Subcharacteristics meliputi analyzability, berubah-ubah, stabilitas, dan testability.
  6. 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).

4)      Kebutuhan Sistem Lingkungan

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.

5)      Kebutuhan User Interface

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.

6)      Evolusi Kebutuhan

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.

7)      Kendala Proyek

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.

 

  • Notasi

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

Sejarah

  • Persaratan Terperinci

Spesifikasi sederhana dalam bahasa alami. Kebutuhan masing-masing memiliki unik identifier. Salah satu contoh yang baik adalah deskripsi item data sebagaimana ditentukan dalam IEEE/EIA-J-STD-016.

  • Spesifikasi Terformat

Spesifikasi diformat menggunakan sintaks akurat didefinisikan, tetapi memungkinkan bahasa alami deskripsi dalam bingkai ini. Contoh termasuk deskripsi kasus digunakan dalam Unified Modeling Language (UML) (Cockburn 2001), yang DRD-100 Kebutuhan Bahasa Spesifikasi, MBASE tersebut SSRD Pedoman (Kitapci et al. 2003), atau Shell Volere (Robertson dan Robertson 1999).

  • Tools

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

1)      kebutuhan elisitasi

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

2)      kebutuhan Validasi

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.

3)      kebutuhan Manajemen

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

6.      Outlook

  • Menghilangkan perbatasan antara pengembangan dan penggunaan sistem
  • Lebih baik integrasi kebutuhan dan arsitektur
  • alat Baru untuk rekayasa kebutuhan didistribusikan
  • RE dalam sistem terbuka

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