BAB II
PEMBAHASAN
KONSEP DAN PRINSIP ANALISIS
2.1 Analisis Persyaratan
Analisis persyaratan merupakan sebuah tugas rekayasa perangkat lunak yang
menjembatani jurang antara alokasi perangkat lunak tingkat sistem dan
perancangan perangkat lunak. Analisis persyaratan memungkinkan perekayasa
sistem menentukan fungsi dan kinerja perangkat lunak, menunjukkan interfasce
perangkat lunak dengan elemen-elemen sistem yang lain, dan membangun batasan
yang harus dipenuhi oleh perangkat lunak.
Analisis persyaratan memberikan model-model yang akan diterjemahkan ke
dalam data, arsitektur, interface, dan desain prosedural kepada perancang
perangkat lunak. Akhirnya, spesifikasi persyaratan memberikan cara kepada
pengembang dan pelanggan untuk menilai kualitas perangkat lunak yang telah
dibangun. Pada awalnya, analis mempelajari spesifikasi sistem (bila ada) dan
rencana proyek perangkat lunak. Penting untuk memahami perangkat lunak dalam
suatu konteks sistem dan mengkaji ruang lingkup perangkat lunak yang telah
digunakan untuk memunculkan estimasi perencanaan. Selanjutnya adalah membangun
komunikasi untuk analisis untuk menjamin pengenalan masalah. Tujuannya adalah
mengenali elemen masalah dasar seperti dirasakan oleh pelanggan.
2.2 Teknik Komunikasi
Analisis persyaratan perangkat lunak selalu dimulai dengan komunikasi
antara dua bagian atau lebih.
A.
Mengawali Proses
Teknik
analisis yang paling umum digunakan untuk menjembatani jurang komunikasi antara
pelanggan dan pengembang dan sekaligus untuk memulai proses komunikasi adalah
dengan melakukan pertemuan pendahuluan dan wawancara. Pertemuan pertama antara
perekayasa perangkat lunak (analis) dan pelanggan dapat disamakan dengan
kakunya kencan pertama antara dua remaja. Keduanya tidak tau apa yang akan
mereka katakan/tanyakan, keduanya merasa mengkhawatirkan yang mereka katakan
akan disalahartikan. Akan tetapi, komunikasi harus diawali.
Menurut Gause dan Weinberg [GAU89] menyarankan agar
analis memulainya dengan mengajukan pertanyaan bebas konteks, dimana pertanyaan
tersebut berfokus pada pelanggan, tujuan keseluruhan, dan keuntungan.
Contoh:
- Siapa di balik permintaan untuk
pekerjaan ini?
- Apa keuntungan ekonomi dari
pemecahan yang berhasil?
- Rangkaian pertanyaan berikutnya
memungkinakan analis mendapatkan pemahaman yang lebih baik mengenai
masalah dan pelanggan, untuk menyatakan persepsinya terhadap suatu
pemecahan.
Contoh:
- Masalah apakah yang akan diselesaikan oleh pemecahan
ini?
- Dapatkah anda memperlihatkan kepada saya atau
menjelaskan lingkungan dimana pemecahan tersebut akan digunakan?
Rangkaian pertanyaan berikutnya berfokus pada efektifitas pertemuan.
[GAU89] memberikan contohnya sebagai berikut:
- Apakah ada orang lain yang dapat memberikan informasi
tambahan?
- Apakah ada hal lain yang harus saya tanyakan kepada
anda?
Pertanayan-pertanyaan
tersebut akan membantu anda mengawali komunikasi yang perlu untuk berhasilnya
analisis. Pada dasarnya sesi tanya jawab seharusnya digunakan pada pertemuan
pertama dan kemudian diganti dengan format yang mengkombinasikan lemen-elemen pemecahan masalah, negosiasi,
dan spesifikasi.
B. Teknik Spesifikasi Aplikasi yang Terfasilitasi
Adanya
teknik pendekatan spesifikasi aplikasi yang teratasi / facilitated aplication
spesification techniques (FAST) dapat mendorong munculnya tim gabungan antara
pengembang dan pelanggan yang bekerja sama
untuk mengidentifikasi masalah,
mengusulkan elemen pemecahan, menegosiasi pendekatan yang berbeda, dan
mengkhususkan rangkaian pemecahan awal. Banyak
pendekatan yang berbeda terhadap FAST telah diusulkan. Masing-masing pendekatan
menggunakan skenario yang sangat berbeda, tetapi semuanya menerapkan beberapa
variasi tuntutan dasar seperti:
Pertemuan dilakukan di sisi netral dan dihadiri baik oleh pengembang
maupun pelanggan. Aturan
main untuk persiapan dan partisipasi dibuat.
Tim FAST
terdiri dari perwakilan dari bagian pemasaran, rekayasa perangkat lunak,
rekayasa perangkat keras, dan pemanufakturan. Seorang fasilitator dari luar
akan digunakan.
C. Penyebaran Fungsi Kualitas
Disebut juga Quality function deployment (QFD) adalah teknik manajemen
kualitas yang menerjemahkan kebutuhan pelanggan ke dalam persyaratan teknis
bagi perangkat lunak. Pertama kali dikembangkan di Jepang
dan pertama kali digunakan di Kobe Shipyar of Mitsubishi Jeavy Industries, Ltd
pada awal tahun 1970-an. QFD berkonsentrasi pada pemaksimalan kepuasan
pelanggan. Untuk melakukannya, QFD menekankan pemahaman mengenai apa yang
berharga bagi pelanggan dan kemudian menyebarkannya ke seluruh proses rekayasa.
QFD mengidentifikasi tiga tipe persyaratan :
1.
Peryaratan
normal
Sasaran dan tujuan
dinyatakan bagi sebuah produk atau sistem selama pertemuan dengan pelanggan.
Bila persyaratan ini ada, maka pelanggan akan menjadi puas.
Contoh: tipe
tampilan grafis yang diminta, dan tingkat kerja yang didefinisikan.
2.
Persyaratan
yang diharapkan
Persyaratn ini implisit terhadap produk atau sistem
dan sangat fundamental sehinggan pelanggan tidak menyatakanyya secara
eksplisit. Ketidakhadirannya menyebabkan ketidakpuasan.
Contoh : Mudahnya instalasi perangkat lunak.
3.
Exciting
Requirement
Persyaratan ini
sangat diharapkan oleh pelanggan dan terbukti sangat memuaskan bila ada. Misalnya, perangkat
lunak pengolah kata diharapkan
dengan fitur standar. Produk yang disampaikan berisi sejumlah kemampuan layout halaman yang sangat
menyenangkan dan tidak terduga.
Dalam kenyataan, QFD mencakup seluruh proses rekayasa. Tetapi banyak konsep QFD dapat diaplikasikan
ke dalam masalah komunikasi pelanggan yang dihadapi oleh perekayasa perangkat lunak selama
tahap awal analisis persyaratan.
QFD
menggunakan wawancara dan observasi pelanggan, survei, dan pengujian data
historis (misalnya:pelaporan masalah) sebagai data kasar bagi aktivitas
pengumpulan persyaratan. Data-data itu kemudian diterjemahkan ke dalam tabel
persyaratan (consumer’s voice table)
yang dikaji dengan pelanggan.
2.3 Prinsip-prinsip Analisis
Masing-masing metode analisis memiliki titik pandang yang unik. Tetapi
semua metode analisis dihubungkan oleh serangkaian prinsip operasional:
- Domain informasi dari suatu masalah
harus direpresentasikan dan dipahami.
- Fungsi-fungsi yang akan dilakukan
oleh perangkat lunak harus didefinisikan.
- Tingkah laku perangkat lunak (sebagai
suatu urutan kejadian eksternal) harus diwakilkan.
- Model-model yang menggambarkan
informasi, fungsi, dan tingkah laku harus dipecah-pecah dalam suatu cara
yang membongkar suatu detail dalam bentuk lapisan.
- Proses analisis harus bergerak dari
informasi dasar ke detail implementasi.
Dengan mengaplikasikan prinsip-prinsip tersebut, analis
mendekati suatu masalah secara sistematis. Domain informasi diuji sehingga fungsi itu dapat dipahami
secara lebih lengkap. Model-model digunakan sehingga karakteristik fungsi dan
tingkah laku dapat dikomunikasikan dengan cara yang rapi. Pembagian diterapkan
untuk mengurangi keruwetan. Pandangan esensial dan implementasi dari perangkat
lunak diperlukan untuk
mengakomodasi batasan logis
yang dibebankan oleh persyaratan pemrosesan dan batasan
fisik yang dibebankan oleh
elemen sistem yang lain. Perekayasa perangkat lunak yang mempercayai prinsip
tersebut akan dapat lebih mengembangkan spesifikasi perangkat lunak yang
kemudian akan menjadi dasar yang kuat bagi desain.
A.
Domain Informasi
Data
(bilangan, karakter, citra, suara dll) dan control (kejadian), keduanya ada
pada domain informasi dari suatu masalah. Prinsip analisis operasional yang
pertama membutuhkan suatu pengujian domain informasi. Domain informasi berisi
tiga pandangan yang berbeda dari data dan control ketika masing-masing diproses
oleh program komputer.
1.
Muatan informasi mewakili
data dan objek kontrol individual yang terdiri dari beberapa kumpulan informasi
yang lebih besar yang ditransformasikan oleh sejumlah data penting : nama
pembayar, jumlah besir yang dibayarkan, pembayaran keseluruhan, potongan dan
seterusnya.
2.
Aliran informasi mewakili
cara dimana data dan kontrol berubah pada saat masing-masing bergerak melalui
sebuah sistem.
3.
Struktur Informasi mewakili
organisasi internal dari berbagai jenis data dan kontrol.
B.
Pemodelan
Model yang
diciptakan selama annalisis persyaratan melayani sejumlah peran penting :
1.
Model
membantu analisis dalam memahami informasi, fungsi, dan tingkah laku suatu
sistem sehingga membuat tugas analisis persyaratan menjadi lebih mudah dan
lebih sistematis.
2.
Model
menjadi titik fokus bagi kajian sehingga merupakan kunci bagi penentuan kelengkapan,
konsistensi dan akurasi, dan spesifikasi.
3.
Model
menjadi dasar bagi pengerjaan desain, memberi perancang suatu representasi
esensial dari perangkat lunak yang dapat diterjemahkan ke dalam suatu konteks
implementasi.
C.
Pembagian
Masalah
sering menjadi terlalun luas atau terlalu rumit untuk dipahami sebagai satu
kesatuan. Karena itulah kita cendrung membagi maslah seperti itu ke dalam
bagian-bagian sehingga dapat dipahami dengan mudah dan kemudian membangun
interface antara bagian-bagian tersebut, sehingga keseluruhan fungsi dapat
dilakukan. Secara konseptual, pembagian
mendekomposisi suatu masalah ke dalam bagian konstituennya.
D.
Pandangan Esensial dan Implementasi
Pandangan
esensial persyaratan perangkat lunak menyajikan fungsi yang akan dikerjakan dan dan di
informasikan yg akan diproses tanpa melihat detail implementasinya. Contoh:
Pandangan esensial dari fungsi safehome read sensor status.
Tidak
tergantung dari bentuk fisik dari data atau type sensor yang digunakan. Pandangan implementasi persyaratan
perangkat lunak menyajikan manifestasi dunia nyata dari pemrosessan fungsi-fungsi dan struktur
informasi. Contoh:
Input safehome dimana perangkat/ element (sensor) menggunakan pertimbangan pandangan implementasi.
2.4 Prototyping Perangkat Lunak
Analisis harus dilakukan tanpa mengabaikan paradigma rekayasa PL yang
diaplikasikan tapi bentuk yang diambil oleh analis akan bermacam-macam. Dalam
banyak kasus sangat mungkin untuk mengaplikasikan prinsip operasional dan
menarik sebuah model perangkat lunak yang melaluinya sebuah desain dapat
dikembangkan, pengaplikasian prinsip analisis dan penyusunan model perangkat
lunak yang akan dibangun yang disebut prototype untuk penilaian pelanggan dan
pengembang.
A. Pemilihan Pendekatan Prototyping
Paradigma
prototyping dapat terbatas dan tidak terbatas. Pendekatan terbatas sering
disebut : throw away prototyping. Dengan
menggunakan pendekatan tersebut, prototyping sebagai sebuah demonstrasi kasar
dari sebuah persyaratan. Kemudian prototype dikesampingkan dan perangkat lunak
direkayasa dengan menggunakan suatu paradigma yang berbeda. Pendekatan tidak
sering disebut evolusionary prototyping menggunakan
prototyping sebagai bagian utama dari aktivitas analisis yanga akan diteruskan
ke dalam desain dan konstruksi .
Sebelum
perangkat terbatas atau tidak terbatas terpilih, perlu ditentukan apakah sistem
yang akan dibangun dapat menerima prototyping atau tidak. Sejumlah faktor calon
calon prototyping dapt ditentukan : area aplikasi, kompleksitas aplikasi, karakteristik
pelanggan, dan karakteristik proyek.
B. Metode dan Peranti Prototyping
Agar prototyping perangkat lunak efektif, maka harus dikembangkan suatu
prototype dengan cepat sehingga pelanggan dapat menilai hasil dan perubahan
yang direkomendasikan. Untuk melakukan prototyping dengan tepat ada tiga kelas
metode dan peranti generik :
1. Teknik
Generasi Keempat (4GT)
Teknik generasi keempat
meliputi suatu array yang luas dari suatu query database dan bahasa pelaporan,
program dan generator aplikasi, serta bahasa nonprosedural lainnya. Karena 4GT
memungkinkan perekayasa perangkat lunak memunculkan kode yang dapat dieksekusi
dengan cepat maka 4GT ideal untuk prototyping yang cepat.
2. Komponen
Perangkat Lunak Reusable
Pendekatan lain ke rapid
prototyping adalah dengan memasang prototype dengan menggunakan serangkaian
komponen perangkat lunak yang ada. Komponen perangkat lunak dapat berupa sebuah
struktur data (database) atau sebuah komponen arsitektur perangkat lunak (program)
atau komponen prosedural (modul). Komponen perangkat lunak harus dirancang
dengan cara tertentu sehingga memungkinkannya untuk dipakai kembali tanpa harus
mempunyai pengetahuan yang mendetail mengenai kerja internalnya.
3. Lingkungan
Prototyping dan Spesifikasi Formal
Pengembang bahasa-bahasa
formal saat ini berada dalam proses pengembangan lingkungan interaktif yang :
Ø Memungkinkan
seorang analis untuk secara interaktif menciptakan spesifikasi sistem atau
perangkat lunak yang berdasarkan pada bahasa.
Ø Memanggil
peranti otomatis yang menerjemahkan spesifikasi berdasarkan bahasa ke dalam
kode yang dapat dieksekusi.
Ø Memungkinkan
pelanggan untuk menggunakan kode prototype yang dapat dieksekusi untuk
menyaring persyaratan-persyaratan formal.
2.5 Spesifikasi
A. Prinsip Spesifikasi
Spesifikasi tanpa mempedulikan mode dimana kita melakukannya, dapat dilihat sebagai sebuah proses
representasi. Persyaratan diwakilkan dengan suatu cara yg membawa ke arah implementasi
yang berhasil. Berikut ini sejumlah prinsip spesifikasi yang diadaptasi dari kerja Blazer dan
Goldman :
1.
Memisahkan fungsional dari implementasi.
2.
Mengembangkan suatu model dari system yang diperlukan yg meliputi data dan respon fungsional
dari suatu system terhadap berbagai stimulus dari lingkungan.
3.
Membangun konteks dimana PL beroperasi dengan menentukan cara dimana komponen system yg
lain berinteraksi dengan PL.
4.
Menentukan lingkungan dimana system beroperasi dan menunjukan bagaimana sekumpulan agen
yang sangat terjalin bereaksi terhadap stimulus dalam lingkungan.
5.
Menciptakan sebuah model yg kognitif daripada model desain atau implementasi.Model kognitif
menggambarkan sebuah system sebagaimana dirasakan oleh komunitas pemakainya.
6.
Mengenali spesifikasi harus toleran terhadap
ketidaklengkapan dan dapat ditambah.
7.
Membangun muatan dan struktur spesifikasi dengan suatu cara yang akan memungkinkan
spesifikasi dapat ditambah agar dapat berubah.
B. Representasi
Kita mengetahui bahwa persyaratan PL dapat ditentukan dalam berbagai cara. Akan tetapi, bila
persyaratan itu dimasukan pada kertas atau media presentasi electronic, maka diperoleh
panduan sederhana:
- Format dan muatan representasi harus
relevan dengan masalah.
- Informasi yang di isikan kedalm
spesifikasi harus disarangkan.
C. Spesifikasi Persyaratan Perangkat Lunak
Spesifikasi persyaratan PL dibuat pada puncak tugas analisis. Fungsi dan
kinerja yang
dialokasikan pada PL sebagai bagian dari rekayasa system, diperhalus dengan membangun sebuah
diskripsi informasi lengkap,diskripsi tingkah laku dan fungsional lengkap,indikasi
persyaaratan kinerja dan batasan desain, criteria validasi yang sesuai, dan data lain
yang berkenaan dengan persyaratan. The Nation Bureau of Standards, IEE( standard no. 830- 1984) dan
Departement Pertahanan
AS mengusulkan format calon untuk spesifikasi persyaratan perangkatan perangkat
lunak. Berikut merupakan kerangka kerja untuk spesifikasi :
a.Pendahuluan
1.
Refrensi system
2.
Deskripsi keseluruhan
3.
Batasan proyek PL
b. Deskripsi
informsi
1.
Representasi isi informasi
2.
Representasi aliran informasi
3.
Aliran data
4.
Aliran kontrol
c. Deskripsi
fungsional
1.
Pembagian fungsional
2.
Deskripsi fungsional
3.
Gambaran pemrosesan
4.
Retriksi / keterbatasan
5.
Persyaratan kinerja
6.
Batasan desain
7.
Diagram
pendukung
8.
Deskripsi
control
9.
Spesifikasi
control
10.
Batasan desain
d.Diskripsi prilaku
1.
Peryataan system
2.
Event dan tindakan
e.Validasi dan kreteria
1.
Batas
kinerja
2.
Kelas-
kelas pengujian
3.
Respon
PL
4.
Pertimbangan
khusus
f.Bibliografi
g.Lampiran
2.6 Kajian Spesifikasi
Kajian
dari suatu spesifikasi persyaratan perangkat lunak dilakukan baik oleh pelanggan atau pengembang PL. Karena spesifikasi
membentuk dasar bagi desain dan aktivitas rekayasa selanjutnya, maka kajian harus dilakukan
dengan hati-
hati. Kajian
dilakukan pertama kali pada tingkat makroskopik.pada tingkat ini pengkaji akan memastikan bahwa
spesifikasi sudah lengkap, konsisten, dan, akurat.
Pertanyaan - pertayan berikut dapat di ajukan :
1.
Apakah tujun dan sasaran yang diyatakan bagi perangkat lunak tetap konsisten dengan
tujuan dan sasaran system?
2. Apakah interface penting kesemua element system sudah digambarkan?
3.
Apakah aliran informasi dan struktur didefinisikan dengan tepat bagi domain masalah ?
4. Apakah diagram jelas?apakah masing masing dapat berdiri
sendiri tanpa teks
pendamping ?
5. Apakah fungsi mayor tetap ada pada ruang lingkup, dan sudah digambarkan dengan lengkap
dn tepat?
6.
Apakah tingkah laku PL konsisten dengan informasi yang harus diproses dan fungsi harus
dilakukannya?
7. Apakah batasan desain realistis?
8. Apakah resiko teknologis pengembang sudah dipertimbangkan?
9. Apakah criteria validasi dinyatakan secara detail?apakah
criteria tersebut
kuat untuk menggambarkan sebuah system yang berhasil ?
10. Apakah ada inkonsistensi,penghilangan?
11. Apakah kontak dengan pelanggan sudah
lengkap?
12. Apakah pemakai sudah mengkaji manual
pemakai pemulaan atau prototype?
13. Bagaimana estimasi perencanaan mempengaruhi
2. Bentuk
ERD
Contoh :
3. Model
Diagram Use Case
