Carlos E. Otero, Erica Dell, Abrar Qureshi

Presentasi berjudul: "Carlos E. Otero, Erica Dell, Abrar Qureshi"— Transcript presentasi:

1 A Quality-Based Requirement Prioritization Framework Using Binary Inputs
Carlos E. Otero, Erica Dell, Abrar Qureshi Department of Mathematics and Computer Science University of Virginia - College at Wise Wise, VA USA Disampaikan kembali oleh: Eko Prasetyo Teknik Informatika Univ. Pembangunan Nasional Veteran Jawa Timur 2011

2 Abstrak Disamping kebutuhan untuk perangkingan requirement, pencarian metode praktek untuk perangkingan requirement juga sesuatu yang sulit. Metode yang ada memberikan hasil yang konsisten, tapi juga sangat kompleks  Sulit diimplementasikan Metode yang informal hemat waktu dan lebih mudah diterapkan, tapi tidak cocok untuk skenario praktek karena struktur dan konsistensi yang kurang, yang dibutuhkan dalam analisis requirement. Paper ini mengusulkan pendekatan yang mencoba untuk mengkuantisasi kualitas requirement untuk memberikan pengukuran yang mewakili semua kriteria kualitas yang mengidentifikasi spesifikasi proyek software. Pengukuran kualitas yang diturunkan dapat dengan mudah dihitung untuk menyediakan metrik utama bagi perangkingan requirement. Kata Kunci: Requirements Engineering, Requirements Prioritization, Desirability Functions, Software Engineering, Software Quality,Software Process

3 Pendahuluan Kebutuhan perangkat lunak dalam kehidupan meningkat.
Dilema manajer proyek untuk menyelesaikan software dengan bekal sumber daya dan waktu yang terbatas. Beberapa requirement tidak dapat secara penuh selesai jika proyek harus selesai tepat waktu. Untuk meyakinkan bahwa requirement yang diimplementasikan adalah yang paling penting, maka penting untuk merangking requirement secara benar. Dua faktor penting yang dikaitkan dalam perangkingan requirement: benefit dan cost. Riset oleh Herrman (2008) menyimpulkan “We found no methods which estimate benefit for individual requirements” Metode perangkingan yang ada terlalu kompleks untuk diimplementasikan. Trade-off antara konsistensi dan kemudahan, seperti: AHP, Cumulative Voting, dsb.

4 Pendahuluan Metode yang memberikan hasil paling konsisten menjadi paling sulit diimplementasikan. Metode yang lebih informal lebih hemat waktu dan mudah, tapi tidak cocok untuk proyek yang kompleks karena kekurangan struktur dan konsistensi yang dibutuhkan dalam menganalisis sejumlah requirement secara benar. Mengusulkan “novel approach” untuk perangkingan requirement software. Berusaha mengkuantisasi kualitas requirement untuk memberikan pengukuran yang mewakili semua kriteria kualitas yang diidentifikasi bagi suatu proyek software. Ukuran kualitas yang diturunkan dapat digunakan sebagai metrik utama untuk perangkingan requirement.

5 Latar Belakang Wieger (1999), sumber daya yang terbatas berarti ada beberapa requirement yang tidak diimplementasikan. Keputusan yang manakah requirement yang paling penting lebih baik ditentukan diawal fase pengembangan. Metode perangkingan yang disampaikan Herrmann (2008) meliputi pengujian requirement melalui framework benefit dan cost. Requirement dianalisis pada basis benefit (keuntungan) yang didapat dari requirement, dan cost (biaya) pengimplementasian. Umumnya metode perangkingan dilakukan secara kuantitatif dan sistematik. Metode yang lain, pembuatan generalisasi dan pengelompokan sebelum dirangking. Pengelompokan dapat mengurangi waktu yang dibutuhkan untuk perangkingan. Metode yang konsisten: Analytic Hierarchy Process (AHP). Metode perbandingan dengan kumulatif poin: Cumulative Voting (100 point) Metode berbasis machine learning: Case-based Rangking (CBR)

6 Solusi: Novel Approach
Metode harus bisa memberikan penentuan kepentingan relatif dari setiap atribut kualitas yang diidentifikasi. Memberikan representasi seberapa baik requirement mencapai kualitas atribut dan bagaimana kepentingan kualitas atribut pada proyek software. Usulan metode: Satu kali requirement sudah diidentifikasi, sejumlah kualitas atribut diidentifikasi sebagai kriteria evaluasi. Requirement yang mendapat nilai tertinggi akan mendapat level kualitas yang lebih tinggi untuk atribut kualitas tertentu. Menggunakan desirability function untuk menggabungkan semua ukuran kedalam satu nilai tunggal yang mewakili semua kualitas requirement. Fungsi tersebut menggunakan pandangan prioritas setiap atribut kualitas. Hasilnya: seberapa baik requirement mencapai atribut kualitas dan seberapa penting atribut kualitas untuk proyek software yang diidentifikasi.

7 Desirability Function
Desirability Function  Pendekatan yang populer untuk optimasi simultas dari beberapa jawaban. Setiap jawaban sistem dikonversi kedalam fungsi individu di dalam range 0  di  1, di = 1 ketika tujuan tercapai, dan di=0 untuk sebaliknya. Setiap jawaban yang yang ditransformasikan, level dari setiap faktor dipilih untuk memaksimalkan desirability, dengan geometric mean dari m jawaban yang ditransformasi. Vektor requirement:

8 Desirability Function
Setiap requirement dievaluasi dengan sejumlah atribut/faktor kualitas: QA1, QA2,.., QAn. Setiap atribut kualitas didefinisikan dengan m fitur, m>1. Skala evaluasi biner: 0 dan 1. 1 jika ada/benar, dan 0 jika tidak ada/salah. Misal, faktor type, bisa didefinisikan dengan fitur/kriteria: Functional, Imposed, dan Product. Jika requirement mempunyai prioritas paling tinggi (bedasar atribut kualitas type) maka Functional=1, Imposed=1, dan Product=1. Jika prioritas paling rendah maka Functional=0, Imposed=0, dan Product=0. Pengukuran kepentingan requirement ke-j berdasar atribut kualitas ke-i (misal, type), dihitung: Dimana m adalah jumlah fitur/kriteria yang diidentifikasi untuk atribut/faktor kualitas ke-I Komputasi dinormalisasikan pada range 0 – 100, 0 merepresentasikan score terendah 100 merepresentasikan score tertinggi

9 Desirability Function
Semua penilaian requirement didasarkan pada atribut/faktor kualitas yang di-capture menggunakan penilaian matrik Q Setiap nilai yij merepresentasikan skor requirement ke-j didasarkan setiap atribut kualitas i. Untuk menilai kepentingan setiap atribut/faktor kualitas, vektor bobot W dibuat, dimana ri menyatakan kepentingan atribut kualitas QA, skala 0 – 10, 0 menyatakan paling tidak penting 100 menyatakan paling penting.

10 Desirability Function
Informasi dari X, Q, dan W digunakan untuk menghitung nilai desirability bagi setiap requirement dengan matrik d. Setiap nilai dij dari matrik merepresentasikan desirability requirement ke-j berdasarkan setiap individu atribut kualitas ke-I Nilai dij dihitung menurut tujuan analisis requirement. Atribut kualitas yang direpresentasikan secara positif dengan nilai yij yang lebih tinggi ditransformasi menggunakan fungsi maksimasi. Atribut kualitas yang direpresentasikan secara negatif dengan nilai yij yang lebih tinggi (misal, penalti seperti biaya dan resiko) ditransformasi menggunakan fungsi minimasi. L dan U adalah batas nilai terendah dan tertinggi, T adalah target objective (mis, 100 untuk meksimisasi, 0 untuk minimisasi), ri adalah bobot desirability pada atribut kualitas. Ketika dij kurang dari , maka nilai dij diset

11 Desirability Function
Setiap nilai desirability requirement dihitung sebagai geometric mean dari m nilai desirability individu untuk requirement 1, 2, …, n. Nilai ini adalah ukuran prioritas yang diturunkan dari atribut kualitas yang sudah didefinisikan dan kepentingan relatif terhadap proyek.

12 Studi Kasus Evaluates 10 requirements based on the following identified quality attributes: Type, Scope, Customers Satisfaction, Perceived Impact (PMF), Application-Specific Attributes, and Penalties. 1) Type: The type of the requirement. Requirement type is defined with the following features: Functional, Imposed, and Product. 2) Scope: The scope of the requirement. This quality attribute asseses the impact of this requirmenent on the overall system. Requirements that affect many (or all) subsystems are determined to have higher priority than requirements that affect minimal number subsystems. Scope is defined with the following features: Subsystem 1 (S1), Subsystem 2 (S2), …, Subsystem n (Sn) 3) Customer Satisfaction:The number of customers the requirement satisfies. The higher the number of customer the requirement satisfies, the higher the desirabilty of the requirement. Customer Satisfaction is defined with the following features: Customer 1 (C1), Customer 2 (C2), …, Customer n (Cn)

13 Studi Kasus (2) 4) Perceived Impact (PMF): The perceived impact the requirement has on the project based on expert opinion. This quality attribute asks each software lead the question “Is this requirement Perceived as a Major Functionality (PMF)?”. Perceived Impact is defined in terms of all leads (software, hardware, systems). Therefore the features are: Lead 1 (L1), Lead 2 (L2), …, Lead n (Ln) 5) Application-Specific: The attributes that are important to the specific software application. Depending on the application domain (e.g., safety critical systems), requirements dictating a specific functionality will have higher importance. In this case study, application-specific is defined with the following features: Usability (U), Performance (P), Safety (S), Security (S), Reliability, and Interoperability (I). 6) Penalties: The penalties associated with the requirement. Requriements are associated with varied types of penalties, for example cost, risk, complexities, etc. This quality attribute is designed to ask the question “Is the requirement perceived as costly/risky/complex?”. Penalties is defined with the following features: Costly (C), Risky (R), and Complex (Cx).

14

15 Kesimpulan Pendekatan yang sederhana dan terbaca, bisa diimplementasikan dengan spreadsheet sederhana. Pendekatan yang menggabungkan evaluasi kriteria dan fitur untuk memberikan pandangan holistik semua kualitas requirement. Mudah dikembangkan untuk memasukkan tambahan atribut kualitas yang belum dipandang dalam penelitian ini. Memberikan mekanisme untuk mengevaluasi kualitas requirement dalam domain yang berbeda.