============ 8 ===============
Definisi Requirements Interdependencies
Mengelola Requirements interdependencies adalah
mengidentifikasi, menyimpan, dan memelihara informasi
tentang bagaimana kebutuhan saling berhubungan dan
mempengaruhi satu sama lain.
Hal ini juga melibatkan bagaimana memutuskan keterkaitan
informasi yang dibutuhkan dalam berbagai situasi selama
pengembangan perangkat lunak dan bagaimana informasi
tersebut harus disajikan.
Requirements Traceability
A Basic for Understanding Requirements Interdependencies
Requirements tracebility atau rekam jejak kebutuhan harus
kita pahami terlebih dahulu untuk memahami lebih jauh
tentang requirements interdependencies.
Requirements Traceability
Secara umum requirements traceability dapat dicapai dengan
mengasosiasikan beberapa informasi yang terkait antara lain:
Kebutuhan dan komponen sistem yang terkait dapat berguna untuk
kebutuhan tersebut.
Tujuan sistem dan kebutuhan yang berasal dari kebutuhan tersebut.
Perubahan proposal dan kebutuhan yang dapat mengubah sistem.
Requirements Traceability
Sebuah keputusan dan dasar pemikiran serta asumsi yang mendasar.
Kasus uji dan kebutuhan yang pemenuhannya untuk memastikan.
Komponen sistem dan sumber daya yang dibutuhkan untuk menerapkan
kebutuhan.
Kenapa Requirements Tracebility?
Requirements traceability saat ini dianggap sebagai
dukungan yang penting untuk mengembangkan sebuah sistem
perangkat lunak berkualitas tinggi.
Untuk menghindari kesalahan, rekam jejak informasi
diperlukan sebagai dasar bagi keputusan dan tugas-tugas di
sebagian besar tahapan proses pengembangan perangkat
lunak.
Kenapa Requirements Tracebility?
Tracebility juga menyediakan kemungkinan untuk
memastikan semua kebutuhan yang dipenuhi oleh komponen
sistem dan tidak ada fitur yang ditambahkan karena semua
komponen atau fitur dalam sistem harus berhubungan
dengan satu atau beberapa kebutuhan.
Kenapa Requirements Tracebility?
Rekam jejak kebutuhan yang komprehensif mendukung
untuk dihasilkannya kualitas produk yang lebih baik,
meningkatkan baik pengembangan dan pemeliharaan
perangkat lunak, dan berpotensi menurunkan biaya siklus
hidup sistem.
Kenapa Requirements Tracebility?
Ditekankan bahwa dalam praktek traceability (rekam jejak)
bisa ditemukan kasus traceability yang diabaikan, tidak
cukup dan tidak terstruktur.
Hal ini menyebabkan penurunan kualitas sistem,
menyebabkan revisi, meningkatkan biaya proyek dan waktu.
Tipe-tipe Requirements Tracebility
Tipe-tipe Requirements Tracebility
Keterangan:
S = Stakeholder/ pemangku kepentingan
BR = Business Rule/ aturan bisnis
Doc = Previous Documentation/ dokumentasi sebelumnya
C = Component/ komponen
R = Requirement/ kebutuhan
Tipe-tipe Requirements Tracebility
1. Pre-traceability
Pre-traceability mengacu pada aspek-aspek kehidupan
kebutuhan sebelum termasuk dalam spesifikasi kebutuhan
dan berfokus pada memungkinkan pemahaman yang lebih
baik dari kebutuhan.
Pre-traceability termasuk menelusuri elisitasi kebutuhan,
definisi kebutuhan serta evolusi mereka.
Tipe-tipe Requirements Tracebility
1. Pre-traceability
Tipe traceability ini merupakan pondasi untuk mengelola
evolusi dari sistem, karena pre-tracebility memungkinkan
elisitasi bagian dari spesifikasi yang disebabkan perubahan
oleh permintaan khusus, misalnya oleh kebijakan organisasi,
proses bisnis, atau penggunaan sistem.
Tipe-tipe Requirements Tracebility
2. Post-traceability
Post-traceability berkaitan dengan memastikan bahwa
semua kebutuhan dipenuhi oleh sistem melalui
perancangan dan implementasi sistem, dengan
mengaitkan kebutuhan untuk komponen (C), yang
membantu memastikan kebutuhan tertentu.
Tipe-tipe Requirements Tracebility
2. Post-traceability
Post-traceability juga penting untuk integrasi
perubahan dengan memungkinkan identifikasi dampak
dari perubahan terhadap perancangan dan
implementasi.
Tipe-tipe Requirements Tracebility
1. Pre-traceability
Berkaitan dengan produksi kebutuhan dan berfokus
pada domain yang berinteraksi ketika kebutuhan
dikembangkan dan di mana sistem akan dipasang.
2. Post-traceability
Berkaitan dengan penyebaran kebutuhan dan
difokuskan pada perangkat lunak yang dikembangkan
berdasarkan kebutuhan.
Tipe-tipe Requirements Tracebility
Tracebility juga dapat dibedakan menjadi horizontal traceability dan
vertical traceability yang mengacu pada objek informasi terkait
termasuk jenis yang sama atau tidak.
Horizontal traceability berhubungan dengan versi atau varian dari
jenis informasi yang sama, misalnya antara kebutuhan atau antara
komponen sistem.
Vertical traceability berkaitan dengan melacak informasi antara
fase sebelumnya dan selanjutnya dalam proses pembangunan
antara objek informasi dari berbagai jenis.
Meta-model requirements traceability
Meta-model menunjukkan perspektif utama dari
requirements traceability dan juga menunjukkan bahwa ada
beberapa dimensi rekam jejak informasi.
Meta-model requirements traceability
• The source is the physical artifact where the information
is maintained, e.g. requirements specification document,
design document, memorandum, and telephone call.
• This perspective emphasizes the document management
part of traceability, which is important because trace
objects available in persistent sources constitute long-term traceability.
Meta-model requirements traceability
• Source (Sumber) adalah artefak fisik dimana informasi
diperbaiki, contoh: dokumen spesifikasi kebutuhan,
dokumen perancangan, memorandum, dan panggilan
telepon.
• Perspektif ini menekankan rekam jejak bagian mengelola
dokumen, ini penting karena jejak objek tersedia dalam
sumber yang persistent dalam waktu yang lama.
Meta-model requirements traceability
• The stakeholder is the agent involved in the management
of traceability, e.g. the customer, system analyst, and
project manager.
• This perspective emphasizes the importance of different
usage roles when designing and implementing a
traceability system. It also provides the ability to define
who is responsible for various products and decisions
during the development process.
Meta-model requirements traceability
• Stakeholder (Pemangku kepentingan) adalah aktor yang
terlibat dalam managemen rekam jejak, contoh: pelanggan,
system analist, dan manager proyek.
• Perspektif ini menekankan pentingnya penggunaan peran
yang berbeda ketika merancang dan menerapkan rekam
jejak sistem. Hal ini juga menyediakan kemampuan untuk
menentukan siapa yang bertanggungjawab untuk berbagai
produk dan keputusan selama proses pembangunan.
Meta-model requirements traceability
Object refers to the type of information objects that
should be related to each other, e.g. requirement, rationale,
decision, and system component.
Meta-model requirements traceability
Object (Objek) merujuk kepada tipe informasi yang terkait
satu sama lain, contoh: kebutuhan, dasar pemikiran,
keputusan, dan komponen sistem.
Meta-model requirements traceability
Meta-model ini dapat digunakan untuk mewakili beberapa dimensi
traceability, termasuk:
Informasi yang disampaikan,
Dimana disampaikan dan bagaimana,
Siapa stakeholders dan peran mereka dan informasi yang digunakan,
Mengapa objek tertentu dibuat atau diubah.
Tipe Interdependency
Types of interdependency:
1. Structural Interdependencies
2. Constrain Interdependencies
3. Cost/ Value Interdependencies
Tipe Interdependency
1. Structural Interdependencies
Structural interdependencies berkaitan dengan fakta
bahwa apabila diberikan satu set kebutuhan, maka
structural interdependencies dapat diatur dalam struktur
yang hirarkis dan juga bersifat lintas-struktur.
Kebutuhan bisnis tingkat tinggi secara bertahap
didekomposisi menjadi kebutuhan perangkat lunak yang
lebih rinci, membentuk sebuah hirarki.
Tipe Interdependency
1. Structural Interdependencies
Tipe structural interdependencies mempunyai beberapa
kategori yaitu Refined_to, Changes_to, dan Similar_to.
Tipe Interdependency
1. Structural Interdependencies
Refined_to
Kebutuhan tingkat yang lebih tinggi dapat disempurnakan dengan
sejumlah kebutuhan yang lebih spesifik.
Tipe dependensi Refined_to digunakan untuk menggambarkan
struktur yang hirarkis, di mana kebutuhan yang lebih rinci terkait
dengan sumber kebutuhan mereka.
Dalam hal ini, kebutuhan memberikan penjelasan lebih lanjut, lebih
detail atau terdapat klarifikasi tentang sumber kebutuhan. Sumber
kebutuhan dapat dilihat sebagai abstraksi kebutuhan rinci.
Tipe Interdependency
1. Structural Interdependencies
Refined_to
Contoh:
Terdapat sebuah kebutuhan yang menyatakan “Sistem harus mendukung
tindaklanjut pesanan pelanggan setelah pesanan dikirim”.
Dapat disempurnakan dengan “Membandingkan biaya produksi produk
yang berhubungan dengan pesanan pelanggan dengan anggaran
manufaktur untuk produk-produk tersebut, dan sistem harus
memfasilitasi perubahan anggaran manufaktur saat tindaklanjut produk
dalam pesanan pelanggan.
Tipe Interdependency
1. Structural Interdependencies
Changes_to
Kebutuhan yang lama akan digantikan dengan kebutuhan
yang baru apabila ada perubahan versi baru dari
kebutuhan.
Tipe dependensi ini digunakan untuk menggambarkan
sejarah dari kebutuhan, misalnya bagaimana hal tersebut
berkembang dari waktu ke waktu karena ini memungkinkan
untuk menghubungkan berbagai versi menjadi satu
kebutuhan.
Tipe Interdependency
1. Structural Interdependencies
Changes_to
Contoh:
Terdapat kebutuhan “Itu harus mengambil waktu tidak lebih
dari 10 detik untuk mencari informasi kontak” dapat diubah
menjadi versi baru sebagai berikut “Itu harus mengambil
tidak lebih dari 5 detik untuk mencari informasi kontak”.
Tipe Interdependency
1. Structural Interdependencies
Similar_to
Salah satu kebutuhan dinyatakan mirip atau tumpang tindih
dengan satu atau lebih kebutuhan lainnya.
Tipe interdependency ini menggambarkan situasi dimana satu
kebutuhan mirip atau tumpang tindih dengan kebutuhan lainnya
dalam hal bagaimana dinyatakan atau dalam hal ide dasar yang
sama tentang apa yang harus dilakukan oleh sistem.
Tipe Interdependency
1. Structural Interdependencies
Similar_to
Contoh:
Terdapat kebutuhan:
“Sistem harus mendukung pengelolaan barang perpustakaan”
dan “Sistem harus menyediakan sarana untuk menangani buku
dan jurnal dalam perpustakaan”.
Kedua kebutuhan tersebut mirip karena buku dan jurnal
dapat dianggap sebagai item perpustakaan.
Tipe Interdependency
2. Constraining Interdependencies
Saling ketergantungan yang lebih rinci dapat diidentifikasi
untuk menggambarkan bagaimana kebutuhan dapat
menghambat satu sama lain atau tergantung satu sama lain.
Terdapat 2 kategori untuk tipe constraining
interdependencies yaitu Requires dan Conflicts_with.
Tipe Interdependency
2. Constraining Interdependencies
Requires
Pemenuhan satu kebutuhan tergantung pada pemenuhan
kebutuhan lain. Jenis dependensi ini digunakan untuk
menggambarkan bahwa jika salah satu kebutuhan
dimasukkan ke dalam sistem, memerlukan kebutuhan lain
untuk dimasukkan juga.
Contoh: Jika sistem harus dapat memasukkan email dan
WebAccess, harus ada koneksi jaringan (yang diperlukan).
Tipe Interdependency
2. Constraining Interdependencies
Conflicts_with
Sebuah kebutuhan bertentangan dengan kebutuhan lain jika
tidak bisa melakukan fungsinya pada waktu yang sama atau jika
salah satu meningkatkan/ mengurangi fungsi dari kebutuhan
yang lain.
Jenis dependensi ini termasuk yang tidak mungkin apabila
menerapkan kedua kebutuhan secara bersamaan, dan situasi di
mana kebutuhan memiliki pengaruh negatif kepada kebutuhan
lain dan resolusi kebutuhan harus dilakukan.
Tipe Interdependency
2. Constraining Interdependencies
Conflicts_with
Contoh: Jika terdapat kebutuhan menyatakan bahwa
”Semua personel harus dapat mencari informasi tentang
produk dan pelanggan” dan state lain menyatakan
”Hanya personel dengan status keamanan yang diizinkan
mencari informasi tersebut”,
kedua hal ini bertentangan satu sama lain dan tidak dapat
digunakan secara bersamaan.
Tipe Interdependency
3. Cost/ Value Interdependencies
Cost/ Value Interdependencies berkaitan dengan biaya
yang terlibat dalam pelaksanaan kebutuhan dalam
kaitannya dengan nilai pemenuhan kebutuhan yang akan
dirasakan oleh pelanggan atau pengguna.
Terdapat 2 kategori dari jenis interdependency ini yaitu
Increases/ Decreases_cost_of dan Increases/
Decreases_value_of.
Tipe Interdependency
3. Cost/ Value Interdependencies
Increases/ Decreases_cost_of
Jika salah satu kebutuhan dipilih untuk proses implementasi,
maka biaya implementasi kebutuhan yang lain bisa bertambah
atau berkurang. Hal ini digunakan untuk menghubungkan
kebutuhan yang mempengaruhi implementasi.
Contoh: Jika kebutuhan menyatakan bahwa tidak ada waktu
respon lebih dari 0.5 detik, kemungkinan besar akan
meningkatkan biaya.
Tipe Interdependency
3. Cost/ Value Interdependencies
Increases/ Decreases_value_of
Jika salah satu kebutuhan yang dipilih untuk implementasi,
maka nilai kebutuhan untuk pelanggan bisa bertambah atau
berkurang.
Tipe ini berfokus pada hubungan pengaruh antara
kebutuhan dan nilai yang dirasakan pelanggan. Beberapa
kebutuhan mungkin memiliki pengaruh positif terhadap
satu pelanggan, sementara bisa memiliki pengaruh negatif
terhadap pelanggan lain.
Tipe Interdependency
3. Cost/ Value Interdependencies
Increases/ Decreases_value_of
Contoh: Kepuasan pelanggan mungkin akan meningkat ketika
kalender perencanaan di masukkan ke dalam ponsel, jika ada
kemungkinan untuk menyingkronkan dengan kalender
perencanaan yang ada di PC.
Mengenal Turnitin – SRE 4803
Turnitin adalah Software untuk mengecek Plagiarism
Di mulai hari ini untuk semua tugas SRE akan menggunakan
Turnitin (Belajar menulis kreatif dan mencegah plagiarism)
Silahkan buka : https://turnitin.com/newuser_type.asp?lang=en_us
Buatlah akun sebagai student
Login untuk kelas SRE 4803 dengan
Class ID: 9968842
Password: sre4803
Mengenal Turnitin – SRE 4806
Turnitin adalah Software untuk mengecek Plagiarism
Di mulai hari ini untuk semua tugas SRE akan menggunakan
Turnitin (Belajar menulis kreatif dan mencegah plagiarism)
Silahkan buka : https://turnitin.com/newuser_type.asp?lang=en_us
Buatlah akun sebagai student
Login untuk kelas SRE 4806 dengan
Class ID: 9968849
Password: sre4806
Create Akun Turnitin
Akun Turnitin
Klik Class SRE-4803, Lalu Submit tugas dan lihat hasil
pekerjaan Kelompok Anda, Toleransi Kemiripan Laporan 30%
Lampirkan Hasil Turnitin di Laporan Tugas Anda
============= 11 Impact Analysis ============
Pengertian Impact Analysis
Analisis dampak adalah alat untuk mengendalikan perubahan
dan untuk menghindari kerusakan.
Bohner dan Arnold mendefinisikan analisis dampak sebagai
“aktifitas mengidentifikasi konsekuensi potensial, termasuk
efek samping dan efek perubahan, atau memperkirakan apa
yang perlu diubah untuk mencapai perubahan sebelum
dibuat.”
Impact Analysis
Output dari analisis dampak dapat digunakan sebagai dasar
untuk memperkirakan biaya yang terkait dengan perubahan.
Biaya perubahan dapat digunakan untuk memutuskan apakah
akan diterapkan tergantung pada rasio biaya/ manfaatnya.
Impact Analysis
Analisis dampak merupakan bagian penting dari rekayasa
kebutuhan karena perubahan perangkat lunak sering
diprakarsai oleh perubahan kebutuhan.
Dalam buku rekayasa kebutuhan, analisis dampak diakui
sebagai suatu kegiatan penting dalam manajemen perubahan,
namun rincian tentang bagaimana melakukan hal tersebut
sering ditinggalkan, atau terbatas pada penalaran tentang
dampak perubahan pada spesifikasi kebutuhan.
Impact Analysis
Hal ini dijelaskan pada gambar di bawah ini. Perhatikan
bahwa proses pembangunan kurang idealis, situasi masih
memungkinkan; perubahan kebutuhan mempengaruhi semua
representasi sistem yang ada.
Software life-cycle objects (SLOs) yang terkena dampak (kanan) akibat
perubahan kebutuhan dalam fase yang berbeda (kiri)
Impact Analysis
Software life-cycle objects (SLOs) atau disebut juga
produk perangkat lunak, atau produk hasil kerja) adalah
pusat untuk analisis dampak.
Sebuah SLO adalah sebuah artefak yang dihasilkan selama
proyek, seperti kebutuhan, komponen arsitektur, kelas dan
sebagainya.
SLO saling terhubung satu sama lain melalui hubungan
jaringan. Hubungan dapat terjadi antara SLO dari jenis yang
sama, dan antara SLO dari berbagai jenis.
Impact Analysis
Sebagai contoh, dua kebutuhan dapat saling berhubungan
untuk menandakan bahwa mereka berhubungan satu sama
lain.
Sebuah kebutuhan juga dapat dihubungkan ke komponen
arsitektur, misalnya, untuk menandakan bahwa komponen
menerapkan kebutuhan.
Impact Analysis
Analisis dampak sering dilakukan dengan menganalisis
hubungan antara berbagai entitas dalam sistem. Dibedakan
menjadi dua jenis analisis:
1. Analisis ketergantungan
Hubungan rinci antara entitas program, misalnya variable atau fungsi yang
diambil dari source code
2. Analisis rekam jejak.
Analisis hubungan yang telah diidentifikasi selama pengembangan antara semua
jenis SLO. Dengan demikian analisis rekam jejak cocok untuk menganalisis hubungan
antara kebutuhan, komponen arsitektur, dokumentasi dan sebagainya.
Impact Analysis
Arnold dan Bohner mendefinisikan set dalam analisis dampak
menjadi 4 bagian yaitu:
1. System set
2. Starting Impact Set
3. Estimated Impact Set
4. Actual Impact Set
Impact Analysis
1. System set merupakan himpunan semua SLO dalam sistem
– semua set lain adalah himpunan bagian dari himpunan ini.
2. Starting Impact Set (SIS) merupakan sekumpulan objek
yang awalnya harus diubah. SIS biasanya berfungsi sebagai
masukkan untuk mempengaruhi pendekatan analisis yang
digunakan untuk menemukan Estimated Impact Set.
Impact Analysis
3. Estimated Impact Set selalu meliputi SIS dan oleh karena itu
dapat dipandang sebagai perluasan dari SIS.
Hasil pengembangan dari penerapan aturan propagasi perubahan
model objek internal yang berulang-ulang sampai semua benda yang
mungkin akan terpengaruh ditemukan.
Idealnya SIS dan EIS harus sama, yang berarti dampak terbatas
pada apa yang awalnya dianggap berubah.
Impact Analysis
4. Actual Impact Set, memiliki SLO yang telah terpengaruh
setelah perubahan telah dilaksanakan.
Dalam scenario kasus terbaik, AIS dan EIS adalah sama, yang
berarti bahwa estimasi dampak yang sempurna.
Impact Analysis
Hal ini umum untuk membedakan antara perubahan primer dan
sekunder.
Perubahan primer, juga disebut sebagai dampak langsung,
sesuai dengan SLO yang diidentifikasi dengan menganalisis
bagaimana efek dari perubahan yang diusulkan mempengaruhi
sistem.
Analisis ini biasanya sulit untuk mengotomatisasi karena
didasarkan pada keahlian manusia.
Impact Analysis
Dampak tidak langsung terdiri dari dua bentuk:
1. Side effects (efek samping) adalah perilaku yang tidak
diinginkan yang dihasilkan dari modifikasi yang diperlukan untuk
melaksanakan perubahan. Efek samping mempengaruhi stabilitas
dan fungsi dari sistem dan harus dihindari.
2. Ripple effects (efek riak) adalah efek pada beberapa bagian
dari sistem yang disebabkan oleh perubahan ke bagian lain. Efek
riak tidak dapat dihindari, karena mereka adalah konsekuensi
dari struktur dan implementasi sistem. Efek riak bagaimanapun
harus diidentifikasi dan dihitung ketika perubahan dilaksanakan.
Perubahan Kebutuhan
Perubahan perangkat lunak terjadi karena beberapa alasan,
misalnya:
dalam rangka untuk memperbaiki kesalahan,
untuk menambahkan fitur baru atau
merestrukturisasi perangkat lunak untuk mengakomodasi
perubahan di masa depan.
Perubahan kebutuhan adalah salah satu motivasi yang paling
signifikan untuk perubahan perangkat lunak.
Perubahan Kebutuhan
Faktor-faktor yang dapat menimbulkan perubahan kebutuhan
selama pengembangan serta evolusi perangkat lunak menurut
Leffingwell dan Widrig adalah:
1. Masalah bahwa sistem seharusnya untuk memecahkan
perubahan, misalnya karena alasan ekonomi, politik atau
teknologi.
2. Para pengguna mengubah pikiran mereka tentang apa yang
mereka inginkan dari sistem, karena mereka memahami
kebutuhan mereka dengan lebih baik. Hal ini dapat terjadi
karena pengguna awalnya tidak yakin tentang apa yang
mereka inginkan.
Perubahan Kebutuhan
3. Lingkungan di mana sistem dilakukan perubahan. Misalnya,
peningkatan kecepatan dan kapasitas komputer dapat
mempengaruhi harapan dari sistem.
4. Sistem baru dikembangkan dan dirilis menuntut pengguna
untuk menemukan kebutuhan baru.
Perubahan Kebutuhan
Maciaszek menunjukkan: “Change is not a kick in the teeth,
unmanaged change is”.
Dengan kata lain, sebuah organisasi yang mengembangkan
perangkat lunak membutuhkan proses manajemen perubahan
yang tepat untuk mengurangi resiko kebutuhan yang terus
berubah dan dampaknya pada sistem.
Perubahan Kebutuhan
Leffingwell dan Widrig membahas lima (5) bagian penting dari
proses untuk mengelola perubahan.
Dalam gambar di bawah ini dijelaskan, pembentukkan kerangka
kerja untuk manajemen proses perubahan yang memungkinkan tim
proyek untuk mengelola perubahan dengan cara yang terkontrol.
Kerangka kerja manajemen proses perubahan
Perubahan Kebutuhan
• Plan for change membahas fakta bahwa telah terjadi
perubahan yang merupakan bagian penting dari pembangunan
sistem. Persiapan ini penting untuk perubahan yang akan
diterima dan ditangani secara efektif.
• Baseline requirements berarti untuk merekam set
kebutuhan. Hal yang ditekankan dari langkah ini
memungkinkan perubahan berikutnya dalam kebutuhan yang
stabil, yang dikenal dengan set kebutuhan.
Perubahan Kebutuhan
• Single channel diperlukan untuk memastikan bahwa tidak ada
perubahan yang diimplementasikan dalam sistem sebelum diteliti
oleh seseorang, atau beberapa orang yang mengawasi sistem,
proyek dan anggaran.
• Dalam organisasi yang lebih besar, single channel sering disebut
Change Control Board (CCB) atau papan pengendalian perubahan.
Perubahan Kebutuhan
• Change control system memungkinkan CCB untuk mengumpulkan,
melacak dan menilai dampak perubahan.
• Menurut Leffingwell dan Widrig, perubahan harus dinilai dampak
biaya dan fungsinya.
• Perubahan mungkin berdampak pada stakeholder eksternal
(misalnya pelanggan) dan berpotensi mengacaukan sistem. Jika hal
ini diabaikan, sistem yang ditunjukkan sebelumnya cenderung
memburuk.
Perubahan Kebutuhan
Manage hierarchically untuk mengelola hirarki mungkin
diperlukan tindakan:
Perubahan yang diperkenalkan dalam kode oleh programmer yang
ambisius,
Efek potensial perubahan yang telah di uji,
Perancangan arsitektur kebutuhan dan sebagainya.
Perubahan harus diperkenalkan secara top-down, dimulai
dengan kebutuhan. Jika kebutuhan yang kadaluarsa dan terkait
dengan SLO lainnya mungkin diperlukan perubahan dengan cara
yang terkontrol.
Perubahan Kebutuhan
Kerangka di atas untuk proses perubahan dan menentukan suatu
proses perubahan yang sebenarnya. Proses yang diusulkan oleh
Kotoya dan Sommerville merupakan proses yang rinci dan terdiri
dari langkah-langkah berikut:
1. Analisis masalah dan spesifikasi perubahan
2. Mengubah analisis dan biaya, yang pada gilirannya terdiri dari:
Periksa validitas permintaan perubahan
Cari kebutuhan yang terkena dampak secara langsung
Cari kebutuhan yang terkait
Mengusulkan perubahan kebutuhan
Menilai biaya perubahan
Menilai biaya penerimaan
3. Perubahan implementasi
Analisis dampak dilakukan dalam langkah-langkah
2b, 2c dan 2e, dengan mengidentifikasi kebutuhan
dan komponen sistem yang terpengaruh oleh
perubahan yang diusulkan. Analisis harus
dinyatakan dalam usaha yang dibutuhkan, waktu,
uang dan sumber daya yang tersedia.
Strategi untuk analisis dampak
Ada berbagai strategi untuk melakukan analisis dampak,
beberapa diantaranya lebih erat dengan proses rekayasa
kebutuhan daripada yang lain. Strategi umum analisis dampak
adalah:
1. Menganalisis rekam jejak atau ketergantungan informasi
2. Memanfaatkan teknik slicing
3. Konsultasi spesifikasi perancangan dan dokumentasi lainnya
4. Wawancara dengan developers yang berpengetahuan
Strategi untuk analisis dampak
Strategi analisis dampak ke dalam dua kategori:
1. Automatable dan
2. Manual.
Strategi untuk analisis dampak
1. Automatable
Strategi analisis dampak automatable sering menggunakan
metode algoritma untuk mengidentifikasi perubahan dan
dampak tidak langsung.
Sebagai contoh, hubungan grafik untuk kebutuhan dan SLO
lainnya dapat digunakan dengan algoritma untuk
mengidentifikasi dampak perubahan yang diusulkan pada
sistem.
Strategi untuk analisis dampak
1. Automatable
Prasyarat untuk strategi automatable adalah spesifikasi
terstruktur dari sistem, berarti bahwa spesifikasi konsisten
dan lengkap termasuk beberapa informasi semantik
(misalnya, jenis hubungan).
Setelah itu, spesifikasi dapat digunakan oleh alat untuk
melakukan analisis dampak secara otomatis.
Ketergantungan kebutuhan dalam web dan model objek
adalah contoh spesifikasi terstruktur.
Strategi untuk analisis dampak
1. Automatable
Strategi secara otomatis membahas rekam jejak dan analisis
ketergantungan, biasanya digunakan untuk menilai perkiraan
dampak dengan mengidentifikasi perubahan sekunder yang
diperlukan karena perubahan utama sistem. Strategi otomatis
tidak cocok untuk mengidentifikasi dampak langsung.
a. Traceability/ Dependency Analysis
b. Slicing Techniques
Strategi untuk analisis dampak
1. Automatable
Strategi secara otomatis membahas rekam jejak dan analisis
ketergantungan, biasanya digunakan untuk menilai perkiraan
dampak dengan mengidentifikasi perubahan sekunder yang
diperlukan karena perubahan utama sistem. Strategi otomatis
tidak cocok untuk mengidentifikasi dampak langsung.
a. Traceability/ Dependency Analysis
b. Slicing Techniques
Strategi untuk analisis dampak
a. Traceability/ Dependency Analysis
Analisis rekam jejak dan analisis ketergantungan melibatkan
pemeriksaan hubungan antara entitas dalam perangkat lunak,
keduanya berbeda dalam lingkup dan tingkat detail.
Analisis rekam jejak adalah analisis hubungan diantara semua
jenis SLO, sedangkan analisis ketergantungan adalah analisis
ketergantungan tingkat rendah yang diambil dari source code.
Strategi untuk analisis dampak
b. Slicing Techniques
Slicing (mengiris) mencoba untuk memahami ketergantungan
menggunakan irisan independen dari program.
Program ini diiris menjadi irisan dekomposisi, yang berisi tempat
perubahan, dan sisa dari program.
Slicing didasarkan pada data dan keterkaitan dalam program ini.
Perubahan yang dilakukan pada potongan dekomposisi sekitar
variabel yang diiris didasarkan pada slice pelengkap yang tidak
terpengaruh.
Strategi untuk analisis dampak
2. Manual
Strategi analisis dampak manual tidak tergantung pada
spesifikasi terstruktur seperti yang terdapat pada strategi
automatable. Akibatnya, ada resiko yang kurang tepat dalam
prediksi dampak secara manual.
Di sisi lain, strategi manual lebih mudah untuk
memperkenalkan proses manajemen perubahan, dan biasanya
digunakan dalam industri tanpa memperhatikan ketepatan
strategi manual tersebut.
Strategi untuk analisis dampak
2. Manual
Strategi manual dalam hal ini menggunakan design
documentation dan interviews, digunakan untuk menilai
dampak awal dengan mengidentifikasi dampak langsung.
Identifikasi dampak sekunder mungkin dilakukan, tetapi
lebih baik ditangani oleh strategi automatable. Strategi
manual dapat digunakan untuk menangkap link traceability
antara SLO untuk digunakan dalam analisis rekam jejak.
Strategi untuk analisis dampak
2. Manual
Keberhasilan dan ketepatan kegiatan ini tergantung pada sejumlah faktor:
1. Pengetahuan dan keterampilan orang-orang yang melakukan analisis
Orang dengan sedikit wawasan tentang sistem kemungkinan besar akan memiliki
masalah dalam menentukan dampak perubahan kebutuhan dalam sistem.
2. Ketersediaan dokumentasi
Dokumentasi yang “tersembunyi” di komputer pribadi atau disimpan dalam binder
anonim dapat diabaikan dalam analisis.
3. Jumlah informasi yang disampaikan dalam dokumentasi
Sketsa sederhana perancangan yang umum gagal untuk mengekspresikan hubungan
semantik antara kelas atau komponen arsitektur. Skema penamaan yang dipilih atau
notasi yang tidak konsisten membuat tugas analisis sulit.
4. Dokumentasi yang jelas dan konsisten
Dokumentasi yang ambigu terbuka untuk interpretasi, misalnya dampak dari
perubahan yang diusulkan ditambah dengan ketidakpastian yang besar, hanya
karena penafsiran lain akan menghasilkan dampak yang berbeda.
Strategi untuk analisis dampak
Strategi automatable memiliki kemampuan untuk
memberikan estimasi dampak yang sangat halus dalam mode
otomatis, tetapi membutuhkan keberadaan infrastruktur
rinci dan mengakibatkan pada waktu yang terlalu banyak
salah.
Dengan strategi manual, dilakukan oleh orang-orang yang
terbaik atau manusia (sebagai lawan alat). Ini membutuhkan
infrastruktur yang kurang, tetapi mungkin memiliki estimasi
dampak yang kasar daripada yang automatable.
Impact Analysis Metrics
Metrik berguna dalam analisis dampak karena berbagai
alasan.
Metrik dapat digunakan untuk mengukur dan menghitung
perubahan yang disebabkan oleh kebutuhan baru atau
kebutuhan yang diubah pada analisis dampak.
Metrik juga dapat digunakan untuk mengevaluasi proses
analisis dampak itu sendiri setelah perubahan telah
dilaksanakan.
Impact Analysis Metrics
Menentukan seberapa parah atau mahalnya sebuah
perubahan merupakan hal yang berguna untuk menentukan
faktor-faktor dampak.
Lindvall mendefinisikan faktor dampak pada tabel di bawah
untuk mengukur dampak dari perubahan yang disarankan.
Faktor dampak didasarkan pada temuan empiris di mana
ditetapkan bahwa perubahan jenis SLOs dapat digunakan
sebagai indikator tingkat perubahan. Semakin tinggi faktor
dampak, semakin parah perubahan.
Metrik untuk mengukur Dampak Perubahan
Faktor dampak Dampak Deskripsi
M1 Perubahan model
obyek
perancangan
Perubahan ini menganggap deskripsi nyata atau fisik
sistem dan dapat menghasilkan perubahan dalam
arsitektur perangkat lunak tentang ukuran perubahan
dalam model.
M2 Perubahan model
obyek analisis
Perubahan ini menganggap deskripsi ideal atau logis dari
sistem. Perubahan kecil dapat menghasilkan perubahan
dalam arsitektur perangkat lunak yang lebih besar
daripada perubahan dalam model ini.
M3 Perubahan model
obyek domain
Perubahan ini menganggap kosakata yang dibutuhkan
dalam sistem. Perubahan kecil di sini dapat menghasilkan
perubahan besar dalam arsitektur perangkat lunak.
M4 Perubahan model
use case
Perubahan ini memerlukan penambahan dan penghapusan
dengan model use case. Perubahan kecil di sini mungkin
memerlukan perubahan besar dalam arsitektur
perangkat lunak.
Alat Pendukung
Kompleksitas dari proses manajemen perubahan membuat
perlu untuk menggunakan beberapa jenis alat pendukung.
Sebuah alat manajemen perubahan dapat digunakan untuk
mengelola kebutuhan dan SLO lainnya, mengelola permintaan
perubahan, permintaan perubahan link kebutuhan dan SLO
lainnya, dan memantau kemajuan analisis dampak.
Alat Pendukung
Sebuah database atau spreadsheet sederhana dapat
digunakan sebagai dukungan manajemen perubahan
mendasar, tetapi masih membutuhkan cukup banyak
pekerjaan manual, yang pada akhirnya dapat menyebabkan
inkonsistensi dalam manajemen perubahan data.
Alat Pendukung
Dalam sebuah survei fitur dari 29 alat manajemen kebutuhan
pendukung traceability, hanya bisa menemukan sembilan alat yang
secara eksplisit dinyatakan di situs web mereka bahwa mereka
mendukung traceability antara kebutuhan dan SLO lainnya,
seperti elemen desain, uji kasus dan kode.
Hal ini menunjukkan bahwa dalam banyak kasus itu perlu untuk
menggunakan beberapa alat yang berbeda untuk mengelola
traceability dan melakukan analisis dampak, yang dapat menjadi
masalah tergantung pada tingkat integrasi antara alat.
Alat Pendukung
Contoh alat pendukung untuk melakukan analisis dampak adalah:
Egyed
Dalam tool ini diusulkan sebuah pendekatan untuk mengekstraksi
dependensi terutama untuk source code.
Masukan untuk pendekatan adalah seperangkat skenario
pengujian dan beberapa jejak hipotesis yang menghubungkan
skenario SLO.
Pendekatan kemudian menghitung footprint dari skenario, yaitu
baris source code yang menutupi, dan berdasarkan footprint dan
hipotesis jejak menghasilkan jejak yang tersisa.
============ 13 Negotiation ===============
Tujuan Requirements Negotiation
Tujuan utama dari negosiasi kebutuhan adalah untuk
mengidentifikasi dan menyelesaikan konflik antar para
stakeholder (pemangku kepentingan).
Ini memberikan kontribusi untuk tujuan mendefinisikan
kebutuhan yang layak dan mengakomodasi semua tujuan
dan harapan stakeholder.
Tujuan Requirements Negotiation
Selain itu, terdapat beberapa tujuan dari negosiasi
kebutuhan yaitu:
1. Memahami kendala proyek
2. Beradaptasi dengan perubahan
3. Membina pembelajaran tim
4. Memunculkan pengetahuan yang dipahami
5. Mengelola kompleksitas
6. Berurusan dengan ketidakpastian
7. Menemukan solusi yang lebih baik
Definisi Negosiasi
Negosiasi diadopsi secara luas dan telah diteliti oleh
berbagai disiplin ilmu. Akibatnya, ada perspektif yang
berbeda pada negosiasi dan aspek berbeda yang
ditekankan.
Negosiasi secara tradisional dipandang sebagai "interaksi
aktual antara peserta yang mengarah pada komitmen
bersama dimulai saat peserta mulai berkomunikasi
mengenai tujuan mereka, dan berakhir atau berhasil ketika
semua setuju untuk kontrak tertentu.”
Definisi Negosiasi
Easterbrook mendefinisikan negosiasi sebagai
"pendekatan kolaboratif untuk menyelesaikan konflik
dengan eksplorasi berbagai kemungkinan.” Hal ini ditandai
oleh peserta yang mencoba untuk menemukan penyelesaian
yang memuaskan semua pihak sebanyak mungkin.
Definisi Negosiasi
Curtis B, Krasner H, Iscoe N mengambil perspektif
rekayasa kebutuhan ketika menyatakan bahwa “negosiasi
kebutuhan dapat dilihat sebagai proses berulang dimana
para pemangku kepentingan membuat timbal balik antara
fungsi sistem yang diminta, kemampuan teknologi yang ada,
jadwal pengiriman dan biaya.”
Definisi Negosiasi
Robinson dan Volkov berpendapat bahwa di luar negosiasi
yang sebenarnya kita juga harus mempertimbangkan tahap
pra dan pasca-negosiasi sebagai bagian dari proses
kegiatan negosiasi meliputi seperti pengakuan awal
masalah, ajakan peserta dan komunikasi, atau pemeliharaan
solusi.
Proses Negosiasi
Proses negosiasi meliputi 3 pendekatan yaitu:
1. Pre-Negotiation,
2. Negotiation, dan
3. Post-Negotiation.
Proses Negosiasi
1. Pre-Negotiation
Kegiatan penting dari tahap ini adalah:
Definisi masalah negosiasi,
Identifikasi pemangku kepentingan,
Elisitasi tujuan dari para pemangku kepentingan, dan
Analisis tujuan untuk menemukan konflik.
Hasil dari tahap ini adalah isu-isu dan konflik yang terlibat.
Proses Negosiasi
2. Negotiation
Kegiatan negosiasi adalah tentang penataan masalah dan
mengembangkan alternatif untuk pemecahan masalah,
misalnya dengan bertukar penawaran atau mengusulkan
alternatif yang saling menguntungkan.
Setelah mengembangkan solusi yang mungkin pemangku
kepentingan akhirnya setuju pada yang “terbaik”.
Proses Negosiasi
2. Negotiation
Penjelasan dari solusi yang mungkin merupakan prasyarat
sebelum para pemangku kepentingan dapat menyetujui
keputusan dan membutuhkan pembentukan kriteria penilaian,
seperangkat aturan yang disepakati oleh semua pemangku
kepentingan.
Diperlukan juga sesi negosiasi untuk menyetujui kriteria
penilaian.
Proses Negosiasi
3. Post-Negotiation
Dalam fase ini pemangku kepentingan (atau alat otomatis)
menganalisis dan mengevaluasi hasil negosiasi dan
menyarankan kembali negosiasi jika diperlukan.
Sebagai contoh, dapat ditentukan perjanjian sesuai
permintaan stakeholder dan jika solusi yang lebih baik
mungkin bagi satu pihak yang melakukan negosiasi, tanpa
menyebabkan kerugian ke pihak yang lain.
Hal ini juga dapat melibatkan evaluasi jaminan kualitas dari
hasil negosiasi.
Dimensi Requirements Negotiation
Dimensi ini terbagi ke dalam tiga kerangka yaitu
1. Strategi resolusi konflik,
2. Kolaborasi situasi para pemangku kepentingan, dan
3. Alat pendukung negosiasi.
Dimensi Requirements Negotiation
1. Strategi resolusi konflik
Konflik merupakan bagian tak terelakkan dari desain
sistem dan alasan untuk negosiasi. Di dalam setiap proyek
rekayasa perangkat lunak, konflik adalah hal penting dan
membutuhkan solusi sebagai keputusan penting.
Dimensi Requirements Negotiation
1. Strategi resolusi konflik
Sebuah studi yang dilakukan oleh Curtis membagi 3
sumber konflik dalam rekayasa perangkat lunak, yaitu:
1. Pengetahuan yang sedikit tentang domain aplikasi,
2. Kebutuhan yang fluktuatif dan saling bertentangan, dan
3. Kurangnya komunikasi dan koordinasi.
Dimensi Requirements Negotiation
1. Strategi resolusi konflik
Berdasarkan Easterbrook sumber konflik diantaranya adalah
Konflik karena perbedaan solusi yang disarankan,
Konflik yang disebabkan karena kendala pernyataan,
Konflik karena kebutuhan,
Konflik dalam penggunaan sumber daya, dan
Konflik karena perbedaan evaluasi prioritas.
Dimensi Requirements Negotiation
1. Strategi resolusi konflik
Terdapat sebuah model yang diusulkan oleh Thomas.
Menurut model ini stakeholder mempunyai dua dimensi
orientasi yakni:
1). Fokus pada memuaskan kepentingannya sendiri (tidak
tegas, asertif) dan
2). Fokus pada memuaskan kepentingan orang lain (tidak
kooperatif, kooperatif).
Dimensi Requirements Negotiation
1. Strategi resolusi konflik
Dengan menggunakan 2 dimensi tersebut dapat ditentukan 5 orientasi
dominan untuk menangani konflik, yaitu:
Bersaing (memaksa) melibatkan penekanan pada memenangkan
kepentingan sendiri dengan mengorbankan yang lain, yang sering
menimbulkan situasi "menang-kalah".
Menampung (lebih halus) mencoba untuk memuaskan kekhawatiran
lain tanpa memperhatikan kepentingan sendiri. Hal ini berarti bahwa
satu pemangku kepentingan rela berkorban dan mengorbankan yang
lain.
Dimensi Requirements Negotiation
1. Strategi resolusi konflik
Berkolaborasi (pemecahan masalah) berfokus pada memnuhi
kepentingan semua pihak untuk mencari alternatif sehinggan memnuhi
kepentingan semua. Menekankan pada situasi “win-win solution”.
Menghindari (menarik diri dari forum) Negosiasi bisa menghasilkan
ketidakpedulian, penolakan, atau apatis.
Berkompromi (berbagi) Melibatkan konsesi untuk menemukan jalan
tengah yang memuaskan.
Dimensi Requirements Negotiation
2. Kolaborasi situasi para pemangku kepentingan
Waktu negosiasi dan lokasi stakeholder memiliki dampak yang kuat pada
interaksi yang sebenarnya selama negosiasi dan menimbulkan tantangan
tambahan. Computer-Supported Cooperative Work telah mengembangkan
matriks CSCW, skema klasifikasi sederhana yang membedakan empat
skenario yang berbeda.
Co-located Dislocated
Synchronous
communication
Same time/ Same place Same time/ Different place
Asynchronous
communication
Different time/ Same place Different time/ Different place
Dimensi Requirements Negotiation
2. Kolaborasi situasi para pemangku kepentingan
Same time/ Same place
• Pertemuan dengan tatap muka masih merupakan cara yang umum
untuk memperoleh dan bernegosiasi mengenai kebutuhan. Dalam
rekayasa kebutuhan, banyak pendekatan masih bekerja dengan
baik atau bahkan mengharuskan terus menerus dan
mengharuskan kerja tim yang sinkron.
• Pendekatan seperti metode Agile mendukung pertemuan dengan
tatap muka. Contoh yang popular adalah “on-site customer”,
dalam sebuah praktik di eXtreme Programming.
Dimensi Requirements Negotiation
2. Kolaborasi situasi para pemangku kepentingan
Different time/ Same place
• Menyelenggarakan seluruh negosiasi dengan pertemuan
tatap muka biasanya tidak mungkin, bahkan jika
stakeholder terletak di lokasi yang sama.
• Durasi negosiasi sering melebihi waktu workshop dan
umumnya sulit untuk diatur karena kendala waktu.
Dimensi Requirements Negotiation
2. Kolaborasi situasi para pemangku kepentingan
Same time/ Different place
• Apabila tidak mungkin untuk mempertemukan para
stakeholder dengan pertemuan tatap muka, mungkin untuk
mengumpulkan stakeholder pada saat yang sama, dengan
beberapa dari stakeholder berpartisipasi jarak jauh.
• Penggunaan konferensi audio dan video harus menyediakan
bandwidth yang wajar dan bermanfaat dengan interaksi
pada waktu yang sama.
Dimensi Requirements Negotiation
2. Kolaborasi situasi para pemangku kepentingan
Different time/ Different place
• Rekayasa kebutuhan semakin banyak dilakukan dalam
waktu dan lokasi yang berbeda karena semakin banyak
proyek yang dilakukan sehingga mempengaruhi beberapa
organisasi.
• Dengan adanya teknologi canggih untuk berkolaborasi
seperti menjadi sebuah keharusan yang memungkinkan
semua stakeholder untuk berkontribusi di belahan dunia
manapun stakeholder berada.
Dimensi Requirements Negotiation
3. Alat pendukung negosiasi
Negosiasi sering didukung dengan cara tradisional seperti
buku pedoman dan buku pegangan untuk fasilitasi serta alat
rapat pada umumnya bagi semua stakeholder seperti papan
tulis, kertas rencana kerja, dll.
Berdasarkan skala dan kompleksitas proyek dunia nyata
menyarankan penggunaan yang lebih canggih untuk
mendukung negosiasi mulai dari perangkat lunak untuk
berkomunikasi dan agen perangkat lunak cerdas.
Dimensi Requirements Negotiation
3. Alat pendukung negosiasi
Kersten dalam makalahnya memberikan klasifikasi mendalam
tentang alat pendukung negosiasi yang terbagi menjadi 3
yaitu:
Passive support,
Active facilitative support, dan
Pro-active interventive support.
Dimensi Requirements Negotiation
3. Alat pendukung negosiasi
Passive support
Passive support menyediakan infrastruktur untuk negosiasi
dan mendukung semua kolaborasi situasi yang berbeda. Alat
ini mengizinkan semua pihak terlibat untuk mengekspresikan
preferensi, berkomunikasi tentang ide-ide, saling tawar dan
ber-argumen, serta berbagi hasil akhir.
Contohnya adalah email, chatting atau multimedia room.
Dimensi Requirements Negotiation
3. Alat pendukung negosiasi
Active facilitative support
Active facilitative support mampu membimbing para
pemangku kepentingan (stakeholder) terhadap kesepakatan.
Misalnya, dengan mengidentifikasi situasi yang saling
menguntungkan.
Sistem tersebut dapat membantu pengguna dalam
perumusan, evaluasi, dan solusi dari masalah yang sulit. Alat
ini juga mendukung pembuatan konsesi dan konstruksi
penawaran, serta penilaian proses.
Dimensi Requirements Negotiation
3. Alat pendukung negosiasi
Pro-active interventive support
Pada pro-active interventive support mampu mengkoordinasikan
kegiatan para stakeholder. Sebagai contoh, mereka mengkritik
tindakan mereka atau menyarankan kesepakatan apa untuk
diterima. Untuk memberikan kemampuan tersebut akses sistem
menggunakan basis pengetahuan dan menggunakan agen perangkat
lunak cerdas dalam memantau proses negosiasi serta kegiatan
individu negosiator.
Contoh perangkat lunaknya adalah Atin intelligent software agent
augmenting the Inspire system.
Contoh Sistem Negosiasi
Para peneliti dan praktisi telah mengembangkan jenis sistem
negosiasi yang mendukung stakeholder dalam melakukan
negosiasi.
Namun, beberapa dari mereka ditargetkan khusus pada
perangkat lunak negosiasi kebutuhan, sementara sebagian
besar alat yang lain lebih mendukung negosiasi yang lebih
umum.
Contoh alat negosiasi adalah DealMaker, Inspire,
MeetingOne, Negoisst, SimpleNS, SmartSettle, dan
WebNS
=============== 14 Kualitas ========================
Pentingnya Jaminan Kualitas
Meningkatnya kompleksitas, meningkatnya tekanan pasar,
dan tuntutan pelanggan untuk kualitas yang lebih tinggi
membutuhkan suatu kombinasi yang hati-hati untuk dipilih,
divalidasi, dan verifikasi untuk memberikan suatu produk
software yang tepat waktu, sesuai anggaran, dan sesuai
dengan kualitas yang diinginkan
Pentingnya Jaminan Kualitas
Rekayasa kebutuhan adalah bagian awal dari proses
pengembangan software, dan
Semua langkah pembangunan selanjutnya dipengaruhi oleh
kebutuhan, membuat suatu kebutuhan yang berkualitas
merupakan faktor penting untuk keseluruhan kualitas dari
sistem yang dikembangkan.
Pentingnya Jaminan Kualitas
Mengapa penting untuk mendeteksi cacat sedini mungkin?
Sebuah isu yang berasal dari kebutuhan menjalankan resiko
yang mempengaruhi tidak hanya kebutuhan lain, tapi juga
mempengaruhi fase-fase dalam arsitektur, perancangan,
coding dan pengujian.
Kebutuhan dan Jaminan Kualitas
Kualitas adalah hal yang sulit untuk ditentukan karena
merupakan konsep yang rumit, tergantung pada sudut
pandang organisasi dan karakteristik konteks.
Misalnya, apakah lebih sedikit cacat per baris kode yang
sama berkualitas tinggi? Kualitas memiliki arti yang sangat
berbeda dalam situasi yang berbeda.
Kualitas Kebutuhan
Kualitas kebutuhan tergantung pada stakeholder dan
perspektif mereka. Beberapa pandangan yang berbeda perlu
dipertimbangkan dalam rangka untuk menentukan apakah
kualitas berarti dalam konteks tertentu.
Kualitas Kebutuhan
Pandangan pertama pada kualitas adalah Transcendental
View.
Di dalamnya, kualitas dianggap sebagai sesuatu yang
berusaha untuk ideal, tapi tidak akan pernah bisa
menerapkan ideal ini.
Tujuan dari sudut pandang ini adalah untuk mengungkapkan
kompleksitas kualitas konsep pada umumnya.
Kualitas Kebutuhan
• Pandangan kedua, User View mengevaluasi kualitas produk
perangkat lunak sehubungan dengan tujuan untuk
memenuhi tugas-tugas pengguna tertentu.
• Pandangan ketiga, Manufacturing view, fokus pada
tampilan produk selama produksi dan setelah pengiriman.
Hal ini difokuskan pada kepatuhan standard an
mengevaluasi apakah produk tersebut dibangun dengan
benar pertama kali.
Kualitas Kebutuhan
• Pandangan keempat adalah Product View. Fokus pandangan
ini adalah pada aspek kualitas internal produk yang dapat
diukur. Hal ini diasumsikan bahwa memastikan aspek mutu
internal tertentu memiliki dampak kualitas eksternal dan
kualitas dalam penggunaan produk.
• Terakhir, pandangan Value-Based View berhubungan
dengan biaya. Hal ini mempertimbangkan bahwa pelanggan
bersedia membayar untuk kualitas.
Kualitas Kebutuhan
Pemetaan pandangan pada kualitas kebutuhan mengungkapkan
bahwa pihak terkait (stakeholder) diperlukan untuk jaminan
kualitas (QA) kebutuhan.
Kebutuhan harus menggambarkan apa yang mengharuskan
pengguna lakukan dari sistem (User-View).
Selain itu, mereka harus dijelaskan dengan cara yang
memungkinkan developers menghasilkan perangkat lunak secara
efektif dan efisien (Product-View).
Kualitas Kebutuhan
Para Requirements Engineers harus mengikuti standar tertentu
ketika menentukan kebutuhan untuk memastikan kualitas
kebutuhan sejak awal (Manufacturing-View).
Dan terakhir, pelanggan harus memutuskan pada nilai kebutuhan
masing-masing dan biaya pelaksanaan (Value-Based View).
Atribut kualitas untuk kebutuhan
1. Correctness (IEEE, User-View)
Kebutuhan yang diterapkan harus mencerminkan apa yang
diharapkan (dimaksudkan) pengguna dan pelanggan. Artinya,
segala sesuatu yang dinyatakan sebagai syarat adalah
sesuatu yang harus dipenuhi oleh sistem akhir untuk
memenuhi tujuan tertentu (sesuai).
Atribut kualitas untuk kebutuhan
2. Unambiguity (IEEE, Product-View)
Kebutuhan harus memiliki hanya satu interpretasi yang
mungkin. Perhatikan bahwa salah satu kebutuhan mungkin
jelas untuk kelompok stakeholder tertentu, tetapi memiliki
arti yang berbeda untuk kelompok lain.
Hal ini penting untuk melibatkan semua stakeholder dalam
proses rekayasa kebutuhan untuk mendapatkan pemahaman
secara umum.
Atribut kualitas untuk kebutuhan
3. Completeness (IEEE, Product-View)
Semua elemen penting yang relevan untuk memenuhi tugas-tugas pengguna yang berbeda harus dipertimbangkan.
Ini termasuk kebutuhan fungsional dan non-fungsional yang
relevan dan interface ke sistem lain, tanggapan terhadap
semua potensi masukkan ke sistem, semua referensi untuk
gambar dan tabel dalam spesifikasi, definisi dari semua
kebutuhan dan langkah-langkah yang relevan.
Atribut kualitas untuk kebutuhan
4. Consistency (IEEE, Product, Manufacturing-View)
Kebutuhan yang dinyatakan harus konsisten dengan semua
kebutuhan lainnya, dan kendala penting lainnya seperti
pembatasan hardware, pembatasan anggaran, dll.
Atribut kualitas untuk kebutuhan
5. Ranked for Importance/ Stability (IEEE, Product, Value-Based, User-View)
Setiap kebutuhan menentukan seberapa pentingnya sesuatu
atau sering disebut stabilitas. Stabilitas mengungkapkan
kemungkinan perubahan kebutuhan, sedangkan menentukan
betapa pentingnya kebutuhan adalah untuk keberhasilan
proyek (dari sudut pandang value-based dan user).
Atribut kualitas untuk kebutuhan
6. Verifiability (IEEE, Product-View)
Semua kebutuhan harus diverifikasi. Artinya, terdapat suatu
proses untuk mesin atau manusia untuk memeriksa (dengan
biaya yang efektif) apakah kebutuhan terpenuhi atau tidak.
Atribut kualitas untuk kebutuhan
7. Modifiable (IEEE, Product-View)
Semua kebutuhan harus bisa dimodifikasi, yaitu struktur
kebutuhan dan spesifikasi kebutuhan memungkinkan integrasi
perubahan dengan cara yang mudah, konsisten dan lengkap.
Atribut kualitas untuk kebutuhan
8. Traceable (IEEE, Manufacturing-View)
Semua kebutuhan harus bisa dilacak, hal ini harus
memungkinkan agar preferensi kebutuhan dilacak dengan
cara yang mudah. Selain itu harus memungkinkan untuk
identifikasi asal kebutuhan.
Atribut kualitas untuk kebutuhan
9. Comprehensibility (New, Manufacturing, User, Value-Based View)
Kebutuhan yang ditentukan dan diungkapkan dengan cara
yang mudah dipahami oleh semua stakeholder yang terlibat.
Atribut kualitas untuk kebutuhan
10. Feasibility (New, Value-Based, Product-View)
Semua kebutuhan dapat diimplementasikan dengan teknologi
yang tersedia, sumber daya manusia dan anggaran yang
sesuai. Selain itu, semua kebutuhan berkontribusi terhadap
keberhasilan moneter dari sistem, yaitu mereka layak untuk
dimasukkan ke dalam sistem.
Atribut kualitas untuk kebutuhan
11. Right Level of Detail (New, User, Manufacturing, Value-Based View)
Informasi yang diberikan dalam kebutuhan ini cocok untuk
mendapatkan pemahaman yang benar tentang sistem dan
dalam memulai pelaksanaan. Tidak ada yang tidak perlu dalam
implementasi dan detail desain yang ditetapkan dalam
kebutuhan.
Strategi Kualitas Kebutuhan
Mengembangkan perangkat lunak tanpa adanya cacat
adalah hal yang tidak mungkin.
Namun, hal ini memungkinkan untuk mencapai sesuatu yang
optimal antara kualitas dan sumber daya yang tersedia,
mengingat faktor konteks yang spesifik dan pemenuhan
akan kualitas dari perusahaan atau sebuah proyek.
Strategi Kualitas Kebutuhan
Selama fase rekayasa kebutuhan, akan menjadi sangat
penting untuk menentukan strategi kualitas yang
membahas isu-isu kualitas yang dapat dengan mudah
diverifikasi dan divalidasi dalam fase kebutuhan.
Aspek kualitas lain yang tidak dapat ditangani secara
efisien selama tahap kebutuhan harus dibiarkan untuk
tahap selanjutnya.
Strategi Kualitas Kebutuhan
Elemen penting untuk menentukan strategi jaminan kualitas
untuk kebutuhan
Strategi Kualitas Kebutuhan
High quality of requirements
Menentukan kriteria kualitas untuk kebutuhan yang baik.
Kriteria ini dapat bervariasi dari perusahaan ke perusahaan
dan dari proyek untuk proyek. Hal ini penting untuk
menentukan set optimal dan minimal karakteristik kualitas
kebutuhan.
Strategi Kualitas Kebutuhan
Available resources
Menggambarkan upaya yang tersedia, anggaran, perangkat
keras, dan personil untuk melakukan QA selama kegiatan
pengumpulan kebutuhan.
Selain itu, ketersediaan ahli tambahan harus
dipertimbangkan, seperti pendekatan jaminan kualitas
tertentu, stakeholder tertentu di luar rekayasa kebutuhan.
Sumber daya yang tersedia juga berdampak langsung pada
pendekatan QA yang berlaku.
Strategi Kualitas Kebutuhan
Risks
Resiko terkait dengan kebutuhan tertentu, terutama resiko
yang tidak mengharuskan atau menerapkan kebutuhan dengan
cara yang salah, resiko merupakan faktor tambahan yang
mempengaruhi strategi kualitas.
Strategi Kualitas Kebutuhan
Time schedule
Terkait dengan sumber daya yang tersedia dan menentukan
waktu yang tersedia untuk QA pada umumnya dan dalam
tahap kebutuhan khususnya.
Waktu sangat penting karena terkait dengan kegiatan
jaminan kualitas kebutuhan dengan kegiatan lainnya.
Strategi Kualitas Kebutuhan
Organization Aspects
Seperti proses pembangunan, contohnya agile development
atau product domain, (contoh: perangkat lunak desktop atau
airplane control system) mempengaruhi keputusan
pendekatan QA yang digunakan.
Pendekatan QA untuk kebutuhan
Pendekatan QA untuk kebutuhan
Pendekatan jaminan kualitas terbagi menjadi dua kelas yakni
1. Pendekatan Constructive dan
2. Pendekatan Analytical.
Pendekatan QA untuk kebutuhan
1. Pendekatan Constructive
Pendekatan Constructive memastikan bahwa kesalahan yang
diminimalkan selama pembuatan produk (misalnya spesifikasi
kebutuhan).
Contoh pendekatan Constructive dalam fase rekayasa
kebutuhan adalah bagaimana menentukan kebutuhan,
template untuk spesifikasi kebutuhan, pendekatan elisitasi
dan prototyping.
Pendekatan QA untuk kebutuhan
2. Pendekatan Analytical.
Pendekatan Analytical dilakukan pada artefak yang komplit
atau sebagian dengan tujuan untuk mendeteksi masalah.
Pendekatan jaminan kualitas Analytical dapat dibagi lagi
menjadi pendekatan jaminan kualitas static dan
pendekatan jaminan kualitas dynamic (termasuk formal
methods).
Pendekatan QA untuk kebutuhan
2. Pendekatan Analytical.
Perbedaan antara dua kelas adalah bahwa pendekatan dynamic
memerlukan versi executable dari sistem.
Pendekatan pengujian adalah contoh jaminan kualitas dynamic.
Pendekatan QA untuk kebutuhan
2. Pendekatan Analytical.
Pendekatan jaminan kualitas static dapat dilakukan tanpa
mengeksekusi kode. Inspeksi dan verifikasi formal merupakan
contoh pendekatan static.
Ada dalam banyak kasus tidak ada kode yang dieksekusi selama
fase rekayasa kebutuhan. Oleh karena itu, biasanya hanya
pendekatan static yang berlaku.
Terimakasih.. tulisannya sangat berwawasan..
BalasHapusMy blog
masama kakak ^_^
HapusTerimakasi infonya sangat menarik
BalasHapusMy blog