1. Analisis Kebutuhan Perangkat Lunak
2. Teknik Komunikasi
3. Prinsip-prinsip analisis
4. Prototyping perangkat lunak
1.
Analisis
Kebutuhan Perangkat Lunak
Tugas analisis persyaratan
merupakan sebuah proses penemuan, perbaikan, pemodelan, dan spesifikasi. Ruang
lingkup perangkat lunak, yang secara mendasar dikembangkan oleh perekayasa
sistem dan diperbaiki selama perancanaan proyek perangkat lunak, diperbaki
secara detail. Model-model data yang dibutuhkan, aliran kontrol dan
informasi,dan tingkah laku operasional diciptakan. Pemecahan alternatif
dianalisis dan dialokasikan ke berbagai elemen perangkat lunak. Baik pengembang
maupun pelanggan melakukan peran aktif dalam analisis persyaratan dan
spesifikasi. Pelangga berusaha memformulasikan kembali konsep yang tidak jelas
dari fungsi perangkat lunak dan kinerja ke dalam detail yang konkrit.
Pengembang bertindak sebagai interogator, konsultan, dan pemecah masalah.
Analisis Kebutuhan Merupakan sebuah tugas sebuah rekayasa
perangkat lunak (RPL) yang menjembatani antara alokasi perangkat lunak dan
perancangan perangkat lunak. Analisis persyaratan memungkinkan perekayasa sistem
menentukan fungsi dan kinerja perangkat lunak, menunjukkan interface dan
elemen-elemen di dalamnya, 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.
Tujuan analisis kebutuhan
Ada tiga tujuan utama dari proses analasis kebutuhan yang dapat diformulasikan sebagai beriukut :
Ada tiga tujuan utama dari proses analasis kebutuhan yang dapat diformulasikan sebagai beriukut :
1.Mengelola
hasil elistasi kebutuhan untuk menghasilkan dokumen spesifikasi kebutuhan yang
isi keseluruhannya sesuai dengan apa yang diinginkan pengguna (Liu and Yen,
1996).
2.Mengembangkan persyaratan kualitas yang memadai dan rinci, dimana para manajer dapat membuat pekerjaan proyek yang realistis dan staf teknis dapat melanjutkan dengan perancangan, implementasi dan pengujian (Wiegers, 2003).
3.Membangun
pemahaman tentang karakteristik ranah permasalahan dan sekumpulan kebutuhan
untuk menemukan solusi.
Ketiga tujuan tersebut dapat dicapai oleh perekayasa kebutuhan dengan melalui serangkaian tahapan-tahapan aktivitas. Tahapan aktivitas tersebut dijelaskan sebagai berikut.
Tahap Analisis Kebutuhan
Tahap analisis
adalah tahapan pengumpulan kebutuhan-kebutuhan dari semua elemen sistem
perangkat lunak yang akan di bangun. Pada tahap ini dibentuk spesifikasi
kebutuhan perangkat lunak, fungsi perangkat lunak yang dibutuhkan, performansi
(unjuk kerja) sistem perangkat lunak, penjadwalan proyek, identifikasi sumber
daya (manusia , perangkat keras dan perangkat lunak yang dibutuhkan) dan
taksiran biaya pengembangan perangkat lunak.Beberapa tahapan nya yaitu:
Domain Understanding, dalam tahap ini perekayasa kebutuhan perangkat lunak harus mengetahui bagaimana organisasi perusahaan beroperasi dan apa yang menjadi permasalahan pada sistem yg sedang berjalan pada saat ini. perekayasaan perlu memfokuskan kepada ‘Apa’ yg menjadi permasalahan. Perekaysaan hendaknya tidak berhenti pada menemukan “gejala” dari permasalahn itu terjadi untuk menemukan
akar dari pemasalahan dari sistem yg berjalan tersebut.
Requirements Collection, Tahapan ini merupakan tahapan pengumpulan kebutuhan akan sistem yang akan dibangun.Pada tahapan ini diperlukan adanya intekasi intensif dengan pemangku kepentingan terutama dengan pengguna akhir.
Classification,Pada tahapan sebelumnya kumpulan kebutuhan masih tidak terstrukturUntuk itu kebutuhan yang saling berkaitan dikelompokan,baik menurut kelas penggunaanya maupun jenis kebutuhananya. Kebutuhan kebutuhan tersebut diorganisasi ke dalam kelompok yang koheren.Perekayasaan perlu memisahkan antara kebutuhan dan keinginan dari pengguna.
Conflict resolution, Pada tahapan ini adalah menemukan dan menyelesaikan kebutuhan yang di dalamnya terdapat konflik.
Prioritisation,Pada tahapan dilakukan interaksi dengan pemangku kepentingan untukidentifikasikan kebutuhan
prioritas agar sumber daya yang tersedia pada organisasi dialokasikan untuk mengimplementasikan kebutuhan yg terutama dari pemangku kepentingan.
Requirements Checking, Menganalisa sekumpulan kebutuhan dari hasil tahapan sebelumnya untuk memverifikasi dan memvalidasi berdasarkan aspek kelengkapan,konsistensi,dan kebutuhan nyata.
Dalam rekayasa kebutuhan, analisa kebutuhan yang baik hedaklah menitik beratkan
pada ranah permasalahan dan bukan pada ranah solusi.Tujuan utamanya adalah untuk mencapai pemahaman tetang sifat dari ranah permasalahan dan permasalahan yangada didalamnya . Pada dasarnya, analisi kebutuhan diawali dengan spesifikasi (layanan,atribut, properti, kualitas, batasan) dari sistem solusi yang hendak dibangun.
Kegunaan analisis adalah untuk memodelkan permasalahan dunia nyata agar dapat dimengerti.
Kegunaan analisis adalah untuk memodelkan permasalahan dunia nyata agar dapat dimengerti.
2.
TEKNIK KOMUNIKASI
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.
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 bekerjasama untuk mengidentifikasimasalah, 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.
Sebuah
mekanisme definisi (dapat merupakan sebuah lembar kerja, diagram flip, stiker
dinding, atau papan tembok) digunakan. FAST bukanlah obat bagi masalah yang
dihadapi dalam pengumpulan awal berbagai persyaratan, tetapi pendekatan tim
memberikan keuntungan dari banyak sudut pandang, diskusi sesaat, dan
penyaringan, serta merupakan langkah maju konkrit ke arah pengembangan
spesifikasi.
Penyebaran
Fungsi Kualitas
Disebut juga Quality function deployment (QFD)
adalah teknik manajemen kualitas yang menerjemahkan kebutuhan pelanggan ke dalam
persyaratan teknis bagi perangkat lunak.QFD mengidentifikasi 3 persyaratan
[ZUL92] yaitu:
- Persyaratan normal:
- Sasaran dan
- tujuan dinyatakan bagi sebuah produk atau sistem selama pertemuan dengan pelanggan.
Bila
persyaratan ini ada, maka pelanggan akan menjadi puas.
Conoth:
tipe tampilan grafis yang diminta, dan tingkat kerja yang didefinisikan. Persyaratan yang diharapkan:
Persyaratan ini implisit terhadap produk atau
sistem dan sangat fundamental sehingga pelanggan
tidak menyatakannya
secara eksplisit. Ketidakhadirannya menyebabkan
ketidakpuasan. Contoh:
Mudahnya instalasi perangkat lunak.
Exciting
requirment: 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 [AKA90]. Tetapi
banyak
konsep QFD dapat diaplikasikan ke dalam masalah komunikasi pelanggan
yang
dihadapi oleh perekayasa perangkat lunak selama tahap awal analisis
persyaratan.
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 secarasistematis. 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.
- Domain Informasi
- Pemodelan
Model dalam perangkat
lunak harus dapat memodelkan informasi yang ditransformasikan oleh perangkat
lunak, fungsi (dan subfungsi) yang memungkinkan transformasi terjadi, dan
tingkah laku sistem pada saat transformasi terjadi.
Dalam beberapa kasus,
model yang kita buat menggunakan notasi grafis yang menggambarkan informasi,
pemrosesan, tingkah laku sistem, dan karakteristik lain sebagai simbol yang
berbeda dan dapat dikenali. Informasi deskriptif dapat diberikan dengan
menggunakan bahasa natural atau bahasa khusus untuk menggambarkan
persyaratannya.
Prinsip analisis
operasional mengharuskan kita membangun model fungsi dan tingkah laku, yaitu:
A.
Model fungsional: Perangkat lunak
mentransformasi informasi, dan untuk melakukannya, perangkat lunak harus
melakukan paling tidak tiga fungsi genetik: input, pemrosesan, dan output. Pada
saat model fungsional dari suatu aplikasi dibuat, perekayasa perangkat lunak
memfokuskan diri pada fungsi-fungsi masalah khusus. Model fungsi dimulai dengan sebuah model tingkat
konteks tunggal (yakni nama perangkat lunak yang akan dibuat). Dengan
serangkaian iterasi, maka lebih banyak lagi detail fungsional diberikan, sampai
seluruh rancangan dari semua fungsionalitas sistem terwakili.
B. Model tingkah laku: Sebagian besar
perangkat lunak merespon kejadiankejadian
dari dunia
luar. Karakteristik stimulus-respon ini membentuk dasar dari model tingkah
laku. Model tingkah laku menciptakan representasi
pernyataan-pernyataan perangkat lunak dan event-event yang menyebabkan perangkat lunak
mengubah pernyataan. Model yang diciptakan selama analisis persyaratan melayani
sejumlah peran penting:
- Model
membantu analis dalam memahami informasi, fungsi, dan tingkah laku suatu
sistem, sehingga membuat tugas analisis persyaratan menjadi lebih mudah dan
lebih sistematis.
- Model
menjadi titik fokus bagi kajian sehingga merupakan kunci bagi penentuan
kelengkapan, konsistensi, dan akurasi dari spesifikasi.
- Model
menjadi dasar bagi pengerjaan desain, memberi perancang suatu representasi
esensial dari perangkat lunak yang dapat diterjemahkan ke dalam suatu konteks
implementasi. Meskipun metode pemodelan yang digunakan sering menjadi masalah
preferensi personal atau organisasional, aktivitas pemodelan adalah dasar bagi
kerja analisis yang baik.
4.PROTOTYPING PERANGKAT LUNAK
Dalam beberapa hal adalah mungkin
untuk menerapkan analisis operasi prinsip dan memperoleh suatu model software
dari suatu disain yang dapat dikembangkan.
Memilih pendekatan prototipe:
Pendekatan closed-ended disebut lembaran prototype iklan.
- Sebuah prototipe melayani sebagai demonstrasi keras dari kebutuhan.
Pendekatan open-ended disebut evolusiner membuat prototip.
- suatu prototipe bertindak sebagai evolusi pertama dari sistem yang telah selesai.
Prototipe Perkakas dan Metoda:
- Teknik Generasi Keempat
- Komponen Software dapat dipakai kembali
- Spesifikasi Formal dan Lingkungan Prototipe
Spesifikasi Software
Prinsip Spesifikasi
Memisahkan kemampuan dari implementasi
Mengembangkan suatu model menyangkut perilaku yang diinginkan dari suatu system
Menetapkan konteks di mana software beroperasi
Menggambarkan lingkungan di mana sistem beroperasi
Menciptakan suatu model teori dibanding suatu implementasi atau disain model
Spesifikasi adalah suatu model abstrak dari suatu sistem riil
Menetapkan struktur dan isi dari suatu spesifikasi ( mudah untuk diubah)
Petunjuk untuk penyajian:
Isi dan Format penyajian harus relevan kepada masalah
Informasi yang dimasukkan di dalam spesifikasi harus sekumpulan
Diagram dan notasi format lain harus terbatas dalam jumlah dan digunakan secara konsisten.
Penyajian harus bisa berhadap-hadapan kembali
Standar spesifikasi kebuthan software:
IEEE ( standard No. 830-1984) dan U.S. Departemen Pertahanan
Dalam banyak kesempatan, suatu persiapan penggunaan manual harus disajikan untuk menghadiahi perangkat lunak sebagai black-box.
Memilih pendekatan prototipe:
Pendekatan closed-ended disebut lembaran prototype iklan.
- Sebuah prototipe melayani sebagai demonstrasi keras dari kebutuhan.
Pendekatan open-ended disebut evolusiner membuat prototip.
- suatu prototipe bertindak sebagai evolusi pertama dari sistem yang telah selesai.
Prototipe Perkakas dan Metoda:
- Teknik Generasi Keempat
- Komponen Software dapat dipakai kembali
- Spesifikasi Formal dan Lingkungan Prototipe
Spesifikasi Software
Prinsip Spesifikasi
Memisahkan kemampuan dari implementasi
Mengembangkan suatu model menyangkut perilaku yang diinginkan dari suatu system
Menetapkan konteks di mana software beroperasi
Menggambarkan lingkungan di mana sistem beroperasi
Menciptakan suatu model teori dibanding suatu implementasi atau disain model
Spesifikasi adalah suatu model abstrak dari suatu sistem riil
Menetapkan struktur dan isi dari suatu spesifikasi ( mudah untuk diubah)
Petunjuk untuk penyajian:
Isi dan Format penyajian harus relevan kepada masalah
Informasi yang dimasukkan di dalam spesifikasi harus sekumpulan
Diagram dan notasi format lain harus terbatas dalam jumlah dan digunakan secara konsisten.
Penyajian harus bisa berhadap-hadapan kembali
Standar spesifikasi kebuthan software:
IEEE ( standard No. 830-1984) dan U.S. Departemen Pertahanan
Dalam banyak kesempatan, suatu persiapan penggunaan manual harus disajikan untuk menghadiahi perangkat lunak sebagai black-box.
SUMBER
0 komentar:
Posting Komentar