Topik 3 : Analisis 2.1 Definisi Analisis Kebutuhan Analisis kebutuhan adalah proses menemukan permasalahan dan menghasilkan alternatif pemecahan yang relevan. Tujuan tahap analisis adalah untuk mengetahui kebutuhan customer berkaitan dengan sistem perangkat lunak yang diinginkan. Pada tahap ini yang terlibat adalah tim spesifikasi/analisis dan customer (meliputi end-user, manajer dan staf lain yang terlibat). 2.2
Metric (Ukuran) Analisis Kebutuhan
Metric analisis kebutuhan diperlukan untuk : Mengukur apakah suatu kebutuhan didefinisikan dengan baik. Hal ini dapat dilihat antara lain dari persentase spesifikasi kebutuhan yang ambigu dan derajat kelengkapan kebutuhan yang didefinisikan Mengukur apakah inspeksi terhadap pendefinsian kebutuhan dilakukan secara efektif 2.3
Lingkup Tahap Analisis Mengidentifikasi customer (termasuk pengguna) Mendefinisikan dan menspesifikasikan kebutuhan Membangun model analisis Mendefisikan spesifikasi rinci untuk dijadikan panduan dalam melakukan perancangan Mendokumentasikan hasil analisis ke dalam dokumen SKPL (Spesifikasi Kebutuhan Perangkat Lunak) dengan format standar (misal : IEEE, NASA, ITB, dll). Melakukan pengkajian ulang secara formal
2.4 Pendefinisian dan Spesifikasi Kebutuhan Definisi Kebutuhan adalah deskripsi fungsionalitas sistem yang berorientasi pada customer dan batasan-batasan yang menyertai pengoperasian sistem tersebut [SOM00]. Penulisan Definisi Kebutuhan: Menggunakan bahasa natural (english) Æ meskipun secara universal dimengerti, namun tetap dimungkinkan muncul hal-hal berikut yang harus dihindari, antara lain : o ketidakjelasan disebabkan dokumen yang dibuat sulit dibaca karena terlalu rinci o pencampuradukan antara kebutuhan fungsional dan kebutuhan non fungsional o beberapa kebutuhan diekspresikan dengan satu pernyataan Menggunakan format standar (misal : IEEE) Spesifikasi Kebutuhan adalah deskripsi rinci dan terukur dari fungsi-fungsi dan batasan-batasan sistem yang telah didefinisikan [SOM00]. Penulisan Spesifikasi Kebutuhan : Structured language specifications o Bentuk terbatas dari bahasa natural (english) yang digunakan untuk mengekspresikan kebutuhan o Menghilangkan beberapa problem yang diakibatkan oleh ambiguitas dan fleksibilitas
Sering didukung dengan penggunaan pendekatan berbasis form( Form-based specifications) o Form-based specifications, berisi : • Definisi fungsi dan entitas • Deskripsi input dan dari mana datangnya • Deskripsi output dan siapa yang membutuhkannya • Mengindikasikan entitas lain yang dibutuhkam • Kondisi sebelum dan sesudah proses dilakukan (jika diperlukan) • Efek samping dari proses jika ada Notasi Grafis Spesifikasi matematis o
Jenis kebutuhan antara lain : Kebutuhan Data Kebutuhan Fungsional Kebutuhan Non Fungsional Kebutuhan Antarmuka 2.5 Pemodelan Analisis Prinsip Pemodelan Analisis Memodelkan domain data Memodelkan Fungsi Memodelkan perilaku sistem Mempartisi model Mulai dengan fokus pada esensi dari permasalahan Memodelkan Domain Data Memodelkan domain data terdiri dari : Mendefinisikan objek data Mendeskripsikan atribut data Mendefinisikan keterhubungan data Memodelkan Fungsi Memodelkan fungsi terdiri dari : Mengidentifikasi fungsi-fungsi yang mentransformasikan objek data Mengidentifikasi bagaimana aliran data yang terdapat pada sistem Mengidentifikasi entitas yang memproduksi data dan memanfaatkan informasi yang dihasilkan sistem Memodelkan Perilaku Sistem, meliputi : Mengidentifikasi semua state yang dihasilkan sistem Menspesifikasikan event yang menyebabkan perubahan dari satu state ke state yang lain Mempartisi model, meliputi : Melakukan perincian objek data Menyusun hirarki fungsional Merepresentasikan perilaku sistem pada tiap level
Pemodelan analisis berfungsi untuk memberikan gambaran lojik perangkat lunak, data yang diperlukan dan model perilaku dari sistem perangkat lunak yang dikembangkan. Gambar 2. 9 memperlihatkan lingkup pemodelan analisis.
Model data
Model Fungsional
Model Perilaku
Gambar 2.9 pemodelan analisis [PRE01] Pemodelan analisis dimulai dengan : Mendefinisikan pernyataan ruang lingkup sistem Ædapat diperoleh dari dokumen kontrak, dokumen spesifikasi sitem atau dokumen lainnya dan himpunan use-case. Pernyataan ini harus menguraikan fungsi-fungsi dasar yang harus dimiliki sistem, data yang akan menjadi masukan dan keluaran, perilaku sistem, domain informasi dan batasan-batasan secara singkat dan jelas. Mendefinisikan objek-objek dan operasi Æ objek-objek dapat merepresentasikan entitas luar yang memberikan input ke sistem atau yang menerima informasi dari sistem, aliran data atau item data yang ditransformasikan oleh sistem dan penyimpanan data (data store). Sedangkan operasi merepresentasikan proses-proses yang terdapat pada aplikasi. Melakukan pemodelan data Æ pemodelan ini diperlukan untuk meminimalkan kebergantungan objek data terhadap proses, memfokuskan pada pengekspolrasian domain data, membuat suatu model yang memudahkan customer memahaminya dan mengindikasikan keterhubungan antara suatu objek data dengan objek data lainnya. Model ini direpresentasikan dengan Entity Relationship Diagram. Melakukan pemodelan fungsi Æ pemodelan ini diperlukan untuk memperlihatkan prosesproses yang dimiliki aplikasi dan bagaimana proses tersebut mentransformasikan data menjadi informasi. Model ini untuk metode terstruktur direpresentasikan dengan Data Flow Diagram Melakukan pemodelan perilaku Æ pemodelan ini diperlukan untuk memperlihatkan perubahan state yang ditunjukkan sistem atau aplikasi ketika terjadi event yang dibangkitkan dari luar. Model ini direpresentasikan dengan State Transition Diagram Mendefinisikan Spesifikasi Proses Æ masing-masing proses pada Data Flow Diagram yang sudah tidak didekomposisi lagi dideskripsikan spesifikasinya. Mendeskripsikan Kamus Data Æ kamus data diperlukan untuk mendeskripsikan isi atau nilai dari data, baik data yang mengalir ke proses dan dari proses maupun data yang terdapat pada data store.
Pemodelan Data Notasi ERD Î Notasi ERD ditunjukkan gambar 2.10
One common form: object
(0, m) 1
relationship
(1, 1)
object
2
attribute Another common form: object
relationship
1
object (1, 1)
(0, m)
2
Gambar 2.10 Notasi Entity Relationship Diagram [PRE01] Catatan : Untuk kasus di mana data yang terlibat dalam sistem tidak memerlukan penyimpanan (basis data) atau jika objek-objek data tersebut tidak memiliki keterhubungan satu sama lain, maka ERD tidak perlu digambarkan. Pemodelan Fungsional DFD digunakan untuk menggambarkan aliran data yang mengalir dalam sistem atau perangkat lunak. DFD juga menggambarkan fungsi-fungsi yang dimiliki sistem atau perangkat lunak tersebut. Notasi DFD dapat dilihat pada gambar 2.11 Eksternal eksternal
Proses/buble
Aliran data
data store
Gambar 2.11 Notasi Data Flow Diagram [PRE01]
Entitas eksternal/Terminator merepresentasikan suatu entitas yang memberikan informasi ke sistem atau menerima informasi dari sistem. Entitas ekternal dapat berupa manusia, perangkat lunak lain, perangkat keras, dan lain-lain. Proses(buble) merepresentasikan suatu fungsi dari perangkat lunak. Suatu proses akan mentransformasikan suatu informasi menjadi informasi lain. Data store merepresentasikan suatu media yang berfungsi menyimpan data yang diperlukan oleh satu proses atau lebih
Pembuatan DFD Æ terdiri dari diagram konteks dan DFD level selanjutnya. Pembuatan diagram konteks dilakukan dengan tahapan berikut : Menentukan entitas eksternal Menentukan informasi yang mengakir dari entitas luar ke sistem dan sebaliknya Menggambarkan diagram konteks Diagram konteks merupakan diagram level pertama yang memperlihatkan sistem sebagai suatu proses yang berinteraksi dengan lingkungannya. Ada pihak luar yang memasukkan informasi ke dalam sistem dan ada yang menerima informasi dari sistem. Pihak luar bisa berupa sistem lain, perangkat keras, orang atau organisasi. Gambar 2.12 memperlihatkan contoh diagram konteks. Level 0 DFD Example
user
processing
requested
request
video digital video
signal monitor
processor video
NTSC
source
video signal
Untuk membuat DFD lakukan langkah-langkah berikut : Definisikan secara naratif fungsi-fungsi yang dimiliki perangkat lunak Gambarkan proses-proses yang mewakili fungsi yang telah Gambarkan aliran data yang masuk dan keluar dari masing-masing proses Periksa kelogisan dari masing-masing proses dan kekontinuan aliran data Lakukan langkah seperti tersebut di atas untuk level berikutnya
T h e D a ta F lo w H ie ra rc h y
a
x
b
P
y
le v e l 0
le v e l 1
a
c
p2
f
p1
d
p4 p3
e
g
5
b
Gambar 2.13 Data Flow Diagram [PRE01] Catatan untuk pemodelan data : • Semua notasi harus diberi label dengan nama yang memiliki arti DFD sebaiknya terdiri dari beberapa level untuk memperinci proses atau fungsi yang dimiliki perangkat lunak Setiap proses harus diberi label dengan kata kerja atau kata benda yang menunjukkan fungsi. DFD dimulai dengan menggambarkan diagram konteks (DFD level0) Pada diagram konteks entitas eksternal harus digambarkan Setiap anak panah (merepresentasikan aliran data) harus diberi label dengan kata benda Tiap buble (proses) harus diperinci sampai tiap-tiap proses hanya mengerjakan suatu fungsi tertentu Kebanyakan sistem memerlukan 3 sampai 7 level DFD Nama buble/proses harus terdiri dari kata benda atau kata kerja Nama yang dipakai untuk buble , data store, data flow harus konsisten (identitas perlu) Setiap level harus konsisten aliran datanya dengan level sebelumnya Banyaknya buble yang disarankan pada setiap level tidak melebihi 7 buble Dekomposisi berdasarkan kelompok data lebih disarankan (memudahkan aliran data ke storage yang sama) Nama proses yang umum hanya untuk buble yang masih akan didekomposisi Nama proses spesifik (Add , Update, Delete, Calculate, Compare, Merge,….) pada case tool harus disertai dengan Proses spesifikasi (PSPEC) yang jelas Pada proses yang sudah tidak didekomposisi, nama proses dan nama data harus sudah spesifik Aliran ke storage harus melalui proses, tidak boleh langsung dari eksternal entity
Aliran data yang tidak ada data storenya harus diteliti, apakah memang tidak mencerminkan presisten entity (perlu disimpan dalam file atau tabel) yaitu kelak hanya akan menjadi variabel dalam program
Pemodelan Perilaku Pemodelan perilaku banyak diterapkan untuk sistem waktu nyata (real time system). Pemodelan perilaku dilakukan dengan tahapan berikut : Daftarkan seluruh state yang dimiliki sistem. Definisi state adalah himpunan keaadaan yang dapat diamati di mana keadaan tersebut mencirikan perilaku sistem pada waktu tertentu Indikasikan bagaimana terjadinya transisi antar state atau indikasikan event yang terjadi dan bagaimana aksi dari sistem terhadap adanya event tersebut. Definisi event adalah kejadian yang menyebabkan sistem menunjukkan beberapa bentuk perilaku yang dapat diprediksi. Contoh sebuah sistem yang memiliki mode manual dan otomatis, jika operator menekan tombol otomatis maka mode akan beralih dari manual menjadi otomatis. Tertekannya tombol otomatis tersebut merupakan contoh event. Sedangkan aksi didefinisikan proses yang terjadi sebagai konsekuensi dari adanya transisi Gambarkan state transition diagram (STD) Notasi STD diperlihatkan pada gambar 2.14.
sta te event causing transition
Action that occurs
new state
Gambar 2.14 Notasi State Transition Diagram [PRE01] Pendefinisian Spesifikasi Proses Spesifikasi proses dapat dinotasikan dengan : Naratif Pseudocode Persamaan matematika (jika penyangkut formula perhitungan) Flow chart .
Kamus Data Notasi untuk kamus data : Notasi
Arti
=
terdiri dari
+
dan
[...|...]
atau (either or)
{...}n
pengulangan n kali dari ....
(....)
data pilihan
...text...
komentar
Contoh Kamus Data Contoh kamus data diperlihatkan pada gambar 2.15. telephone number
integrated office phone system
system output
Build the requirements dictionary: Name:
telephone number
Aliases:
phone number, number
Where/How used:
read-phone-number (input) display-phone-number (output) analyze-long-distance-calls (input)
Description:
telephone no. = [ local extension | outside no. | 0 ] outside no. = 9 + [ service code | domestic no. ] service code = [ 211 | 411 | 611 | 911 ] domestic no. = ( ( 0 ) + area code ) + local number area code = *three numeral designator*
Format:
alphanumeric data
