uchiha's blog

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:   

1. Siapa di balik permintaan untuk pekerjaan ini?  
2. Apa keuntungan ekonomi dari pemecahan yang berhasil?
3. Rangkaian pertanyaan berikutnya memungkinakan analis mendapatkan pemahaman yang lebih baik mengenai masalah dan pelanggan, untuk menyatakan persepsinya terhadap suatu pemecahan.

Contoh:   

1. Masalah apakah yang akan diselesaikan oleh pemecahan ini?
2. 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:

1. Apakah ada orang lain yang dapat memberikan informasi tambahan?
2. 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:

1. Domain informasi dari suatu masalah harus direpresentasikan dan dipahami.
2. Fungsi-fungsi yang akan dilakukan oleh perangkat lunak harus didefinisikan.
3. Tingkah laku perangkat lunak (sebagai suatu urutan kejadian eksternal) harus diwakilkan.
4. Model-model yang menggambarkan informasi, fungsi, dan tingkah laku harus dipecah-pecah dalam suatu cara yang membongkar suatu detail dalam bentuk lapisan.
5. 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