1. Analisis kebutuhan P.L
Analisa kebutuhan merupakan langkah awal untuk menentukan perangkat lunak seperti apa yang akan dihasilkan, ketika kita melaksanakan sebuah proyek pembuatan perangkat lunak. Perangkat lunak yang baik dan sesuai dengan kebutuhan pengguna sangat bergantung kepada keberhasilan dalam melakukan analisa kebutuhan. Tidak peduli bagaimana hebatnya seseorang dalam menulis kode perangkat lunak, atau membuat antar muka yang menawan, jika terjadi kesalahan dalam analisa kebutuhan, itu artinya perangkat lunak yang dibuat menjadi tak berguna.
Analisa kebutuhan adalah sebuah proses untuk mendapatkan informasi, model, spesifikasi tentang perangkat lunak yang diinginkan klien/pengguna. Kedua belah pihak, yaitu klien dan pembuat perangkat lunak terlibat aktif dalam tahap ini. Informasi yang diperoleh dari klien/pengguna inilah yang menjadi acuan untuk melakukan desain perangkat lunak.
Ada 3 faktor yang harus dipenuhi ketika melakukan analisa kebutuhan ini yaitu : lengkap, detail, dan benar. Lengkap artinya semua yang diharapkan oleh klien telah didapatkan oleh pihak yang melakukan analisa. Sedangkan detail maksudnya adalah berhasil mengumpulkan informasi yang rinci sampai hal-hal yang kecil. Semua data dari analisa kebutuhan ini haruslah benar, sesuai apa yang dimaksud oleh klien, bukan benar menurut apa yang difikirkan oleh pihak yang melakukan analisa. Sebuah kutipan anonim yang sering disampaikan mengenai hal ini adalah : “Saya percaya anda sangat mengerti dengan apa yang saya katakan, namun saya tidak yakin bahwa apa yang anda dengar adalah sama dengan apa yang saya maksud”.
2. Teknik komunikasi
Komunikasi adalah proses penyampaian suatu pesan oleh seseorang kepada orang lain untuk memberi tahu atau untuk mengubah sikap, pendapat, atau perilaku, baik langsung secara lisan, maupun tak langsung melalui media.
TEKNIK KOMUNIKASI
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 [ZAH90].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.
Contoh : 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 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.
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.
• 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 fungsionaldiberikan, sampai seluruh rancangan dari semua fungsionalitas sistem terwakili.
• 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 bagipenentuan 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
Prototyping perangkat lunak adalah salah satu metode siklus hidup sistem yang didasarkan pada konsep working model. Yang bertujuan untuk mengembangkan model menjadi sistem final. Artinya sistem akan dikembangkan lebih cepat daripada metode sebelumnya dan biayanya akan menjadi lebih rendah. Ada banyak cara untuk memprotoyping, begitu pula dengan penggunaannya. Ciri khas dari metodologi ini adalah pengembang sistem (system developer), klien, dan pengguna dapat melihat dan melakukan eksperimen dengan bagian dari sistem komputer dari sejak awal proses pengembangan.
Protoyping juga membantu dalam hal menemukan kebutuhan di tahap awal pengembangan, terutama jika klien tidak yakin dimana masalah berasal. Selain itu protoyping juga berguna sebagai alat untuk mendesain dan memperbaiki user interface – bagaimana sistem akan terlihat oleh orang-orang yang menggunakannya.
5. Spesifikasi dan kajian spesifikasi
Metode spesifikasi sama dengan pemecahan masalah. Pereka PL yang dipaksa bekerja dengan spesifikasiyang tidak lengkap,tidak konsisten,atau salah akan mengalami frustasi atau keraguan.akibatnya, kualitas ,ketepatan waktu dan kelengkapan perangkat lunak menjadi korban.
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[BLA 86].
- Memisahkan fungsional dari implementasi
- Mengembangkan suatu model dari system yang diperlukan yg meliputiData dan respon fungsional dari suatu system terhadap berbagai stimulus dari lingkungan.
- Membangun konteks dimana PL beroperasi dengan menentukan cara dimana komponen system yg lain berinteraksi dengan PL.
- Menentukan lingkungan dimana system beroperasi dan menunjukan bagaimana “ sekumpulan agen yang sangat terjalin bereaksi terhadap stimulus dalam lingkungan.
- Menciptakan sebuah model yg kognitif daripada model desain atau implementasi.Model kognitif menggambarkan sebuah system sebagaimana dirasakan oleh komunitas pemakainya.
- mengenali spesifikasi harus toleran terhadap ketidak lengkapan dan dapat di tambah.
- Membangun muatan dan struktur spesifikasi dengan suatu cara yang akan memungkinkan spesifikasi dapat ditambah agar dapat berubah.
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.
Spesifikasi persyaratan PL
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 kerj untuk spesifikasi.
a. Pendahuluan
- Refrensi system
- Deskripsi keseluruhan
- Batasan proyek PL
b.Deskripsi informsi
- Representasi isi informasi
- Representasi aliran informasi
- aliran data
- aliran kontrol
c.Deskripsi fungsional
- Pembagian fungsional
- deskripsi fungsional
- gambaran pemrosesan
- retriksi / keterbatasan
- persyaratan kinerja
- batasan desain
- diagram pendukung
- diskripsi control
- spesifikasi control
- batasan desain
d.Diskripsi prilaku
- peryataan system
- event dan tindakan
e.Validasi dan kreteria
- batas kinerja
- kelas- kelas pengujian
- respon PL
- pertimbangan khusus
f.Bibliografi
g.Lampiran
~ 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 contohnya
Apakah tujun dan sasaran yang diyatakan bagi perangkat lunak tetap konsisten dengan tujuan dan sasaran system?
- Apakah interface penting kesemua element system sudah digambarkan?
- Apakah fungsi mayor tetap ada pada ruang lingkup, dan sudah digambarkan dengan lengkap dn tepat?
- Apakah tingkah laku PL konsisten dengan informasi yang harus diproses dan fungsi harus dilakukannya?
- Apakah batasan desain realistis?
- Apakah resiko teknologis pengembang sudah dipertimbangkan?
Pengkaji dapat mengembangkan pertayaan diatas dengan :
Mencari konektor persuasive
- Bila suatu daftar yang diberikan tidak lengkap,pastikan jenisnya sudah dipahami.
- Pastikan jangkauan yg dinyatakan tidak berisi asumsi yg tidak dinyatakan.
- Hati hatilah pada kata kerja yang kabur
- Hati hati terhadap kata ganti yang ambiguitas
- Cari pertanyaan yang mengimplimentasikan kepastian Bila kajian lengkap spesifikasi persyaratan PL diakhiri oleh pelanggan atau pengembang.
Perubahan yang diminta setelah spesifikasi itu di akhiri tidak akan dieleminasi, tetapi pelanggan harus mencatat bahwa masing – masing perubahan setelah pengakhiran spesifikasi merupakan ekstensi dari ruang lingkup PL yang demikian dapat menambah biaya dan atau dapat memperpanjang jadwal proyek.Bahkan dengan prosedur kajian terbaikpun, tetap ada sejumlah masalah spesifikasi. Spesifikasi sulit di uji dalam berbagai cara yang berarti sehingga inkonsistensi dan penghilangan dapat berlangsung tanpa terlihat. Selama kajian , perubahan terhadap terhadap spesifikasi dapat disetujui.Sangat sulit untuk menili pengaruh global dari suatu perubahan ; yaitu bagaimana suatu perubahan dalam suatu fungsi mempengaruhi persyaratan bagi fungsi- fungsi yang lain.
http://tekomunikasi.blogspot.com/
http://lokomediasi.blogspot.com/2009/08/prinsip-konsep-analisa-kebutuhan.html
random ♥
No comments
