Cara Menangkap Kebutuhan Software dan Menganalisanya

Modul Makalah - Cara Menangkap Kebutuhan Software dan Menganalisanya - Artikel ini akan membahas tentang dasar analisa kebutuhan. Melalui artikel ini diharapkan mampu memahami bagaimana cara menangkap kebutuhan dan menganalisa nya.

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”
• Custumer “merumuskan ulang” segala sesuatu konsep yang samar-samar mengenai fungsi dan performasi perangkat lunak ke dalam konsep ynga 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 !!!!

image source: www.atsautomation.com

baca juga: Pengukuran Perangkat Lunak Dalam Proses dan Domain Proyek

ANALISA KEBUTUHAN

• Adalah tugas rekayasa perangkat lunak yang menjembatani kesenjangan antara “system level software allocation” and “software design”

Overlap of the analysis task

• Memungkinkan “system engineer” mengspesifikasikan fungsi dan unjuk kerja (performansi) perangkat lunak, menentukan antar muka perangkat lunak dengan elemen sistem lain, dan menetapkan kendala-kendala dalamproses pengdesainan 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.
• 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.

Role of the analyst

PROBLEM AREAS

Analisa keperluan merupakan aktivitas komunikasi yang dilakukan secara intensif

Permasalahan yang mungkin ditemukan pada proses analisa keperluan adalah :

• Kesulitan untuk menggabungkan informasi yang didapat
• Penanganan permasalahan yang kompleks
• Perubahan-perubahan yang akan terjadi selama atau sesudah analisis.

Hal-hal yang menyebabkan permasalahan pada tahap analisa kebutuhan :

• Kurang komunikasi antara pemakai dan analis
• Tehnik yang dipakai kurang baik, juga alat bantu yang digunakan tidak tepat.
• 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.

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.

Information flow

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

c. Struktur informasi :

• 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

Keuntungan

• Membantu meningkatkan pengertian permasalahan sampai detail / rinci
• Memudahkan untuk penganalisaan

a Partisi horisontal dan partisi vertikal.

3. PANDANGAN LOGIKAL DAN FISIKAL

Pandangan logikal :
Gambaran dari fungsi perangkat lunak yang diperlukan telah ditentukan dan informasi yang akan diproses tanpa memandang penerapannya sampai detail / rinci

Pandangan fisikal :
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

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 :

• Sistem / software dialokasikan menggunakan strategi formal, yaitu dengan memakai bahasa untuk mendeskripsikan. Strategi formal dapat dibuat dalam bentuk paragraf tunggal dengan tatabahasa yang benar.
• 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”
• Atribut dari objek diidentifikasi dengan menggarisbawahi semua kata sifat dan kemudian menghubungkannya dengan kata benda (objek) masing-masing.
• Operasi ditetapkan dengan menggarisbawahi semua kata kerja, anak kalimat kata kerja dan predikat, serta menghubungkan setiap operasi dengan objek yang sesuai.
• 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 listwill 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 pulsesthat 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

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

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 :

• Struktur data (database)
• Komponen arsitektur program (program)
• 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.

An automated software engineering paradigm

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
• Menggunakan simbol / bentuk yang terbatas jumlahnya dan digunakan secara konsisten
• Representari dapat direvisi

SOFTWARE REQUIREMENTS SPECIFICATION

1. Introduction

• System reference
• Business objectives
• S / W project constraints

2. Information description

• Information flow representation
• Information content representation
• Information structure representation
• System interface description

3. Functional desciption

• Functional partitioning
• Functional description
  1. Processing narative
  2. Restrictions / limitations
  3. Performance requirements
  4. Design constraints
  5. Supporting diagrams

4. Validation criteria

• Performance bounds
• Classes of tests
• Expected S / W response
• Special considerations

5. Bibliography

6. Appendix

Sekian artikel tentang Cara Menangkap Kebutuhan Software dan Menganalisanya.

Daftar Pustaka

1. Pressman, R. S., Software Engineering: A Practitioner’s Approach, 8th Edition, McGraw-Hill, 2008
2. Sommerville, I., Software Engineering 8th Edition, Addison-Wesley, 2007.