BAB III KONSEP DAN PRINSIP ANALISIS

Transkripsi

1 BAB III KONSEP DAN PRINSIP ANALISIS halaman : 1 Spesifikasi yang lengkap mengenai "Keperluan Perangkat Lunak" merupakan hal yang penting bagi tercapainya kesuksesan dalam usaha pengembangan perangkat lunak. Tugas-tugas analisa kebutuhan meliputi proses penemuan dan perbaikan. Diperlukan komunikasi yang aktif antara "developer" dan "customer" Customer "merumuskan ulang" segala sesuatu konsep yang samar-samar mengenai fungsi dan performasi perangkat lunak ke dalam konsep yang lebih detail / jelas dan rinci. Developer berlaku sebagai "Pemeriksa", "konsultan" dan "pemecah masalah" Analisa kebutuhan dan spesifikasi kelihatannya merupakan suatu tugas yang sederhana. Padahal tidak!!!! ANALISA KEBUTUHAN Adalah tugas rekayasa perangkat lunak yang menjembatani kesenjangan antara "system level software allocation" and "software design".

2 halaman : 2 Memungkinkan "system engineer" menspesifikasikan fungsi dan unjuk kerja (performansi) perangkat lunak, menentukan antar muka perangkat lunak dengan elemen sistem lain, dan menetapkan kendala-kendala dalam proses perancangan perangkat lunak. Memungkinkan "Analyst" untuk menghaluskan alokasi perangkat lunak dan menggambarkan domain informasi yang akan disajikan dengan perangkat lunak. Memberikan gambaran kepada desainer tentang informasi dan fungsi yang dapat diterjemahkan ke dalam : data, arsitektur dan desain prosedur Memberikan kepada developer dan customer tantang perkiraan kualitas perangkat lunak yang akan dibuat / dikembangkan / dibangun. TUGAS-TUGAS ANALISIS Analisa keperluan / kebutuhan perangkat lunak dapat dibagi dalam 4 bidang usaha 1. Pengenalan masalah 2. Evaluasi dan sintesa 3. Spesifikasi 4. Peninjauan ulang Keterangan : 1. Pengenalan masalah : Analisis mempelajari spesifikasi sistem dan rencana proyek perangkat lunak. Penting untuk memahami perangkat lunak dalam konteks sistem dan meninjau ulang batasan perangkat lunak yang digunakan untuk menggenerate perencanaan perkiraan. Komunikasi dalam proses analisa harus ditetapkan sehingga "masalah" dapat dikenali dengan pasti. 2. Evaluasi dan sintesa : Analisis harus melakukan evaluasi "aliran" dan "struktur" dari informasi, menghaluskan semua fungsi perangkat lunak, menetapkan karakteristik antarmuka, dan menemukan kendala-kendala dalam desain.

3 halaman : 3 Proses evaluasi dan sintesa berlangsung sampai analis dan customer merasa yakin bahwa perangkat lunak dapat dibuat spesifikasinya untuk tahap pengembangan. 3. Spesifikasi : Melakukan proses penentuan spesifikasi perangkat lunak, sehingga memudahkan pengerjaan pada tahap pengembangan. 4. Peninjauan ulang Proses meninjau kembali terhadap spesifikasi yang dihasilkan, sehingga diperoleh spesifikasi perangkat lunak yang lebih rinci dan jelas dengan maksud untuk menghasilkan perangkat lunak yang baik. ANALIS Analis harus mempunyai kemampuan : 1. Menganalisa konsep yang belum jelas 2. Menyerap fakta / informasi 3. Mengerti lingkungan pemakai 4. Menerapkan elemen sistem dari perangkat lunak maupun perangkat keras pada lingkungan pemakai 5. Berkomunikasi baik dalam bentuk tulisan maupun lisan.

4 halaman : 4 PROBLEM AREAS Analisa keperluan merupakan aktivitas komunikasi yang dilakukan secara intensif Permasalahan yang mungkin ditemukan pada proses analisa keperluan adalah : o Kesulitan untuk menggabungkan informasi yang didapat o Penanganan permasalahan yang kompleks o Perubahan-perubahan yang akan terjadi selama atau sesudah analisis. Hal-hal yang menyebabkan permasalahan pada tahap analisa kebutuhan : o Kurang komunikasi antara pemakai dan analis o Tehnik yang dipakai kurang baik, juga alat bantu yang digunakan tidak tepat. o o Kecendrungan mempersingkat waktu untuk melakukan analisa Gagal mempertimbangkan alternatif pemecahan masalah. PRINSIP-PRINSIP ANALISA Prinsip-prinsip dasar metode analisa : 1. Domain informasi 2. Permasalahan harus dipartisi 3. Gambaran dari logikal dan fisikal sistem harus dikembangkan.

5 halaman : 5 1. DOMAIN INFORMASI Domain informasi berisi 3 pandangan yang berbeda dari data yang diproses oleh program komputer : a. Aliran informasi : Menggambarkan bagaimana perubahan data dari satu proses ke proses lain. b. Isi informasi : Menggambarkan item-item data yang menyusun item yang lebih besar dan berisikan informasi yang lengkap. Contoh : Record mahasiswa terdiri dari item : nomor mahasiswa, nama mahasiswa, alamat mahasiswa, dan lain-lain.

6 c. Struktur informasi : halaman : 6 Menggambarkan organisasi data secara logika Data-data disusun dalam bentuk tabel, hirarki, atau tree Yang diperhatikan pada struktur informasi adalah bagaimana data item yang ada saling berhubungan. 2. PERMASALAHAN HARUS DIPARTISI Partisi dilakukan agar masalah yang besar bisa dimengerti dengan mudah Keuntungannya: Membantu meningkatkan pengertian permasalahan sampai detail / rinci Memudahkan untuk penganalisaan Partisi Horisontal

7 Partisi Vertikal halaman : 7 3. PANDANGAN LOGIKAL DAN FISIKAL Pandangan logikal : o Gambaran dari fungsi perangkat lunak yang diperlukan telah ditentukan dan informasi yang akan diproses tanpa memandang penerapannya sampai detail / rinci Pandangan fisikal : o Bagaimana penerapan fungsi pemrosesan dan struktur informasi OBJECT-ORIENTED ANALYSIS Pendekatan object-oriented untuk pendefinisian masalah dan partisi cukup baik diterapkan sebagai bagian dari analisa kebutuhan

8 halaman : 8 Pendefinisian dari objek dan operasi adalah cara yang baik untuk memulai analisa terhadap fungsi dan domain informasi Objek : bisa dipandang sebagai suatu item informasi Operasi : sebagai suatu proses atau fungsi yang diterapkan pada satu / lebih objek Pendekatan analisa object-oriented : 0. Sistem / software dialokasikan menggunakan strategi formal, yaitu dengan memakai bahasa untuk mendeskripsikan. Strategi formal dapat dibuat dalam bentuk paragraf tunggal dengan tatabahasa yang benar. 0. Objek diberi garis bawah (kata benda, atau anak kalimat yang bersifat sebagai kata benda) dan kemudian dimasukkan ke dalam tabel. Sinonim dicatat. Jika objek diperlukan untuk mengimplementasikan status solusi, maka object tersebut merupakan bagian dari "solution space". Jika objek hanya diperlukan untuk mendeskripsikan status solusi, maka objek tersebut merupakan bagian dari "problem space" 0. Atribut dari objek diidentifikasi dengan menggarisbawahi semua kata sifat dan kemudian menghubungkannya dengan kata benda (objek) masing- masing. 0. Operasi ditetapkan dengan menggarisbawahi semua kata kerja, anak kalimat kata kerja dan predikat, serta menghubungkan setiap operasi dengan objek yang sesuai. 0. Attribut dari operasi diidentifikasikan dengan menggarisbawahi semua kata keterangan dan mengasosiasikan mereka dengan operasi ( kata kerja ) masing-masing. Contoh masalah CLSS Berdasarkan deskripsi perangkat lunak sebagai strategi informal, kita terapkan langkah pertama : CLSS software will receive input information from a bar code reader at time intervals that conform to the conveyor line speed. Bar code data will be decoded into box identification format. The software will do a lookup in a 1000 entry database to determine proper bin location for the box currently at the reader (sorting station). A FIFO list will be use to keep track of shunt positions for each box as it moves past the sorting station.

9 halaman : 9 CLSS software will also receive input from a pulse tachometer that will be use to synchronize the control signal to the shunting mechanism. Based on the number of pulses that will be generate between the sorting station and the shunt, the software will produce a control signal to the shunt to properly position the box... Bar code data, bin location, dan control signal solution space Lainnya problem space Setiap objek mewakili sebuah item informasi yang harus diproses oleh software Penentuan proses : CLSS software will receive input information from a bar code reader at time intervals that conform to the conveyor line speed. Bar code data will be decoded into box identification format. The software will do a lookup in a 1000 entry database to determine proper bin location for the box currently at the reader (sorting station). A FIFO list will be use to keep track of shunt positions for each box as it moves past the sorting station. CLSS software will also receive input from a pulse tachometer that will be use to synchronize the control signal to the shunting mechanism. Based on the number of pulses that will be generate between the sorting station and the shunt, the software will produce a control signal to the shunt to properly position the box... Solution space : receive, look-up, produce Problem space : moves, synchronize

10 halaman : 10 SOFTWARE PROTOTYPING Tujuan pembuatan "Software Prototyping" : Membantu mengevaluasi apakah desain telah memenuhi spesifikasi fungsional maupun non fungsional Prototype diuji dan disempurnakan sebelum dilakukan produksi software yang sebenarnya. Dalam perekayasaan perangkat lunak, pembuatan prototype merupakan proses produksi Pembuatan prototype bisa membantu : 1. Pendefinisian dan spesifikasi desain yang akan dibuat 2. Pemilihan metode dan algoritma yang akan digunakan dalam desain 3. Pendefinisian spesifikasi interface dengan pemakai

11 halaman : 11 Langkah-langkah yang dapat diterapkan untuk menghasilkan prototype perangakat lunak : 1. Mengevaluasi permintaan / pemesanan perangkat lunak dan menentukan apakah perangkat lunak yang dikembangkan mempunyai peluang yang baik untuk dibuat prototypenya. 2. Setelah "calon proyek" dapat diterima, analis mengembangkan garis besar keperluan / kebutuhan 3. Setelah representasi kebutuhan ditinjau ulang, maka dibuat desain spesifikasi untuk pembuatan prototype 4. Lakukan testing dan penghalusan / perbaikan terhadap prototype perangkat lunak. 5. Prototype perangkat lunak yang sudah ditest, diperlihatkan kepada customer untuk dilakukan uji coba 6. Langkah 4 dan 5 diulangi sampai customer puas dan kriteria validasi terpenuhi. Metoda dan alat bantu pembuatan prototype : 1. Fourth Generation Techniques 2. Reusable software component Menggunakan komponen perangkat lunak yang sudah ada : o Struktur data (database) o Komponen arsitektur program (program) o Komponen prosedural (modul) 3. Formal specification and prototyping environments Metoda ini banyak menggunakan bahasa formal untuk mengembangkan proses interaktif dengan lingkungan luar; Memungkinkan analis membuat spesifikasi untuk mengembangkan proses secara interaktif Menggunakan alat bantu otomatis yang dapat menterjemahkan kode executable Memungkinkan pelanggan menggunakan prototype "executable code" untuk proses penghalusan dalam hal kebutuhan yang diinginkan.

12 halaman : 12 SPECIFICATION Prinsip-prinsip dalam penyusunan spesifikasi perangkat lunak : 1. Memisahkan fungsi dari implementasi 2. Spesifikasi sistem berorientasi kepada keperluan sistem 3. Spesifikasi harus memuat sistem dari perangkat lunak yang merupakan komponen 4. Spesifikasi harus termasuk di mana sistem akan dioperasikan 5. Spesifikasi sistem harus berupa model kognitif 6. Spesifikasi dapat dilaksanakan 7. Spesifikasi sistem harus bertoleransi terhadap ketidaklengkapan dan kemungkinan perluasan sistem 8. Spesifikasi harus dibatasi dan keterkaitannya longgar REPRESENTATION Digunakan untuk menjelaskan metoda yang dipakai untuk menganalisa kekuatan. Petunjuk pembuatan representasi : Format representasi dan isinya harus relevan dengan masalah yang akan dijelaskan Informasi diisi dengan spesifikasi yang dapat bersarang

13 halaman : 13 Menggunakan simbol / bentuk yang terbatas jumlahnya dan digunakan secara konsisten Representari dapat direvisi SOFTWARE REQUIREMENTS SPECIFICATION 1. Introduction a. System reference b. Business objectives c. S / W project constraints 2. Information description a. Information flow representation b. Information content representation c. Information structure representation d. System interface description 3. Functional desciption a. Functional partitioning b. Functional description < 1 >Processing narative < 2 >Restrictions / limitations < 3 >Performance requirements < 4 >Design constraints < 5 >Supporting diagrams 4. Validation criteria a. Performance bounds b. Classes of tests c. Expected S / W response d. Special considerations 5. Bibliography 6. Appendix