RESUME 6

ANALISA DAN PERANCANGAN PERANGKAT LUNAK

Dosen Pembimbing :

Muhammad Adri, S.Pd., M.Pd.T.

Oleh :

Nama : Lisa Rahmanita

Nim : 18076080

PROGRAM STUDI PENDIDIKAN TEKNIK INFORMATIKA

JURUSAN TEKNIK ELEKTONIKA

FAKULTAS TEKNIK

UNIVERSITAS NEGERI PADANG

2021
A. SPESIFIKASI FORMAL
Ada banyak pendukung dan penentang metode formal. Sommerville
(1996) dengan baik merangkum sudut pandang keduanya. Argumen yang
diajukan dalam mendukung metode formal meliputi, selain yang diberikan pada
paragraf sebelumnya, kemungkinan pengembangan program otomatis dan
pengujian. Sayangnya, kisah suksesnya terlalu sedikit, teknik logika dan diskrit
matematika yang digunakan tidak banyak diketahui, dan biaya tambahan untuk
mengembangkan spesifikasi formal adalah dianggap sebagai biaya overhead,
tidak layak dilakukan. Memberikan jalan tengah, Sommerville (1996)
menyarankan menggunakan pendekatan ini untuk (i) sistem interaktif, (ii)
sistem yang mengutamakan kualitas, keandalan dan keamanan kritis, dan untuk
(iii) pengembangan sistem standar.
Meskipun hari ini metode formal sangat maju, teknik grafis dari state
machine yang terbatas, statechart, dan Petri Nets adalah yang pertama untuk
menyalakan imajinasi para insinyur perangkat lunak untuk mengembangkan
metode formal. Dalam materi ini, Kita menyoroti fitur dasar dari metode formal
untuk spesifikasi kebutuhan. Ada sejumlah pendekatan untuk pengembangan
metode formal. Mereka semua menggunakan konsep fungsi, pra-kondisi, dan
pasca-kondisi sambil menentukan persyaratan. Tapi mereka berbeda dalam
notasi matematika dalam mendefinisikannya. Tiga notasi menonjol:
 Metode Pengembangan Vienna (VDM)
 Bahasa Z-Spesifikasi
 Notasi Larch
Dua yang pertama dikembangkan oleh IBM. Mereka mengadopsi notasi
yang digunakan dalam teori himpunan dan orde pertama teori logika dan
mendefinisikan simbol khusus tertentu. Yang ketiga menggunakan notasi
mnemonik yaitu kompatibel dengan keyboard standar. Sommerville menyebut
dua metode pertama sebagai model berbasis dan panggilan notasi Larch aljabar.
Namun ketiganya adalah spesifikasi tipe data abstrak bahasa, yang
mendefinisikan properti formal dari tipe data tanpa mendefinisikan fitur
implementasi. Kita menggunakan bahasa spesifikasi-Z berbasis model dalam
materi ini untuk menyoroti fitur dasar metode formal.

1. Notasi yang Digunakan Dalam Metode Formal

Notasi yang digunakan dalam metode formal biasanya dipinjam
dari yang ada dalam matematika diskrit. Matematika diskrit berkaitan
dengan elemen- elemen diskrit dan operasi yang didefinisikan pada
mereka, dari pada matematika kontinu yang berurusan dengan diferensiasi
dan integrasi. Pressman (1997) memberikan sejumlah dasar notasi yang
digunakan dalam metode formal. Kita membahas di bawah ini beberapa
notasi ini. Spesifikasi set SetSatu adalah kumpulan elemen unik (tidak
berulang). Ada dua cara untuk menentukan satu set:
1. Dengan pencacahan.
2. Dengan membuat spesifikasi set yang konstruktif.

Bentuk umum spesifikasi himpunan konstruktif adalah

{signature/ predicate.term}. Signature menentukan rentang nilai saat
membentuk set. Predikat adalah ekspresi Boolean yang dapat mengambil
nilai benar atau salah dan menentukan bagaimana set akan dibangun. Term
memberi bentuk umum dari setiap elemen di set. Kardinalitas suatu
himpunan adalah jumlah elemen dalam himpunan yang diekspresikan
dengan menggunakan operator #: # {1, 3, 2, 4, 5} = 5; # {n: N ⎜ n <6} =
5; # F = 5 (di mana F adalah himpunan yang didefinisikan sebelumnya). Di
sini operator # mengembalikan jumlah elemen dalam set. Simbol ∅
menunjukkan set nol yang tidak mengandung elemen. Ini sama dengan nol
jumlahnya. Simbol berguna lainnya yang umumnya digunakan dalam teori
himpunan adalah sebagai berikut:
 I : Set bilangan bulat,…, - 2, - 1, 0, 1, 2,…
N : Set angka alami, 1, 2, ...
R : Set semua bilangan real — bilangan bulat dan nilai pecahan negatif
dan positif (berbaring di garis nyata)
R +: Setel semua bilangan real lebih besar dari nol

2. Bahasa Spesifikasi-Z
Blok bangunan utama bahasa spesifikasi-Z adalah struktur
grafis dua dimensi disebut skema. Skema dianalogikan dengan subrutin
atau prosedur bahasa pemrograman. Itu mewakili aspek statis (kondisi) dan
aspek dinamika (operasi pada kondisi) suatu sistem. Skema juga dapat
dinyatakan dalam skema lain. Gambar 6.1 menunjukkan struktur dasar
suatu skema Z.

Nama skema harus bermakna. Nama ini dapat digunakan oleh

skema lain untuk referensi. Tanda tangan menyatakan nama dan tipe entitas
(variabel keadaan) yang menentukan keadaan sistem. Predikat
mendefinisikan hubungan antara variabel-variabel keadaan dengan
menggunakan ekspresi yang harus selalu benar (data invarian). Predikat
dapat menentukan nilai awal variabel, batasan pada variabel, atau
hubungan invarian lainnya di antara variabel. Ketika ada lebih dari satu
predikat, mereka ditulis pada baris yang sama dipisahkan oleh dan operator
𝖠 atau ditulis pada terpisah baris (seolah dipisahkan oleh 𝖠 implisit).
Predikat juga dapat berupa spesifikasi operasi yang mengubah nilai
 variabel keadaan.Operasi mendefinisikan hubungan antara nilai-nilai lama
dari variabel dan parameter operasi untuk menghasilkan nilai-nilai variabel
yang berubah. Operasi ditentukan dengan menentukan pra-kondisi dan
kondisi pasca. Pra- kondisi adalah kondisi yang harus dipenuhi untuk
operasi yang akan dimulai. Pasca kondisi adalah hasil yang bertambah
setelah operasi selesai.
Langkah-langkah untuk mengembangkan Spesifikasi Bahasa Z
Saiedian (1997) telah menyarankan langkah-langkah berikut untuk
mengembangkan spesifikasi bahasa Z untuk persyaratan perangkat lunak:
a. Sajikan definisi yang diberikan, ditentukan pengguna, dan global.
b. Tetapkan status abstrak.
c. Tentukan kondisi awal.
d. Sajikan operasi transisi status.

3. Spesifikasi Bahasa Z untuk Persyaratan Perpustakaan-Ilustrasi

Kita mempertimbangkan persyaratan berikut untuk LibCirSys -
sistem informasi untuk bagian sirkulasi perpustakaan:
a. Seorang pengguna dapat meminjam buku jika buku itu tersedia di
perpustakaan dan jika sudah meminjam kurang dari sepuluh buku.
Pesan ‘OK’ akan muncul di layar setelah operasi checkout. Namun,
jika buku sudah dipinjam oleh pengguna lain atau jika buku itu sudah
dinyatakan hilang, maka pesan ‘Maaf, buku sudah dikeluarkan’ dan
‘Maaf, buku hilang’ akan muncul di layar.
b. Pengguna dapat mengembalikan buku yang telah dipinjamnya. Setelah
operasi check-in yang sukses ini sebuah pesan ‘Buku dikembalikan.’
akan muncul di layar.
c. LibCirSystem dapat ditanyakan untuk mengetahui judul dan jumlah
buku yang dipinjam seorang pengguna kapan saja.
 d. Jika buku tidak tersedia di perpustakaan atau dipinjam oleh pengguna
mana pun untuk jangka waktu satu tahun, itu dinyatakan hilang dan
sebuah pesan now Buku ini sekarang termasuk dalam daftar buku-
buku yang hilang. ’akan muncul di layar. Seseorang tertarik untuk
mengetahui jumlah buku yang hilang. Kita mengikuti empat langkah
pengembangan spesifikasi Z.

Langkah 1: Sajikan Definisi yang diberikan,

Tentukan Pengguna, dan Global Set yang diberikan beirisi detail dari
himpunan (jenis) yang tidak diperlukan, Kita menganggap bahwa himpunan
itu diberikan. Untuk sistem sirkulasi perpustakaan Kita menganggap BUKU
dan PENGGUNA sebagai set yang diberikan. Kita mewakili set yang
diberikan dalam semua huruf besar, dipisahkan dengan titik koma, dalam
kurung. Untuk sistem sirkulasi perpustakaan set yang diberikan adalah:

[BUKU; PENGGUNA]

Langkah 2: Tentukan Status Abstrak

Kita mendefinisikan keadaan buku dalam sistem sirkulasi perpustakaan

sebagai terdiri dari tiga variabel: ‘Tersedia’, ‘dipinjam’, dan ‘hilang’.
Variabel 'tersedia' menunjukkan serangkaian buku yang tersedia di rak
perpustakaan dan dapat dipinjam oleh pengguna. Variabel 'dipinjam'
menunjukkan set buku yang telah dipinjam pengguna. Dan variabel 'hilang'
menunjukkan serangkaian buku yang dideklarasikan hilang; ini adalah buku-
buku yang tidak tersedia atau dipinjam dan belum ditemukan selama
setidaknya satu tahun.

Langkah 3: Tentukan Status Awal

Kita berasumsi bahwa pada awalnya semua buku milik perpustakaan

tersedia di perpustakaan tanpa buku baik dipinjam atau hilang. Gambar 6.4
 menunjukkan skema untuk kasus ini. Perhatikan bahwa skema LibCirSys
dihiasi dengan tanda kutip di bagian tanda tangan, dan variabel yang
termasuk dalam skema ini dan muncul di bagian predikat juga masing-
masing dihiasi dengan tanda kutip.

Langkah 4: Sajikan Operasi Transisi Status (State Transition)

Operasi ini mencerminkan persyaratan perangkat lunak yang

dinyatakan sebelumnya.

B. SPESIFIKASI KEBUTUHAN PERANGKAT LUNAK – SRS

1) Sifat-Sifat dari SRS
Software requirements specification (SRS) memberikan gambaran
dari kebutuhan pengguna. Fungsinya yaitu :
a. Merumuskan konsep yang dimiliki Pengembang dan diungkapkan
secara efektif dan ringkas.
b. Menyampaikan pemahaman ini kepada sponsor hingga mendapatkan
persetujuan.
c. Menjadi acuan di mana perangkat lunak diimplementasikan dan
dipelihara.

Sifat-sifat yang dimiliki SRS adalah sebagai berikut:

a. Hanya mencakup fitur-fitur penting dari sistem yang diperbaiki,

diketahui, dan disepakati untuk disampaikan.
b. Mencakup apa yang harus disampaikan, bukan bagaimana
menyampaikannya. Dengan demikian rincian implementasi harus
diambil selama tahap desain saja.
c. Harus menggunakan kosakata yang dipahami klien.
d. Harus benar. Misalnya, dapat dikatakan bahwa ia akan memproses
50.000 dokumen dalam satu jam, sedangkan dalam praktiknya
mungkin tidak dapat memproses lebih dari 20.000 dokumen - sebuah
kasus dengan spesifikasi yang salah.
e. Harus tepat. Misalnya, hanya mengatakan bahwa sejumlah besar
dokumen dapat diproses atau bahwa akan memakan waktu sangat
sedikit untuk memproses dokumen itu tidak tepat.
f. Tidak ambigu. Misalnya, pernyataan harus menyampaikan hanya satu
makna.
g. Harus lengkap. Pernyataan “basis data harus diperbarui jika transaksi‘
tipe- beli ’” tidak lengkap; itu harus menunjukkan jenis tindakan yang
harus diambil jika transaksi bukan 'tipe pembelian'.
h. Harus dapat diverifikasi. Setelah suatu sistem dirancang dan
diimplementasikan, harus dimungkinkan untuk memverifikasi bahwa
desain/ implementasi sistem memenuhi persyaratan asli
(menggunakan metode analitik atau formal).
i. Harus valid. Pengguna harus dapat membaca/ memahami spesifikasi
kebutuhan dan menunjukkan sejauh mana persyaratan tersebut
mencerminkan ide-idenya.
j. Harus konsisten. Pernyataan di satu tempat SRS dapat mengatakan
bahwa pesan kesalahan akan muncul dan transaksi tidak akan diproses
jika inventaris menjadi negatif.
k. Dapat dimodifikasi. Struktur dan gaya SRS harus sedemikian rupa
sehingga setiap perubahan yang diperlukan untuk persyaratan dapat
dibuat dengan mudah, lengkap, dan konsisten.
l. Mudah ditemukan. Kebutuhan harus memberikan referensi antara
aspek desain/ implementasi dan aspek persyaratan.
2) Isi Sebuah SRS
SRS harus memiliki isi berikut:
a. Kegunaan
Ini menunjukkan layanan yang disediakan oleh sistem perangkat lunak yang
dibutuhkan oleh pelanggan dan pengguna.
b. Deskripsi Lingkungan dan Tujuan Sistem
1. Atribut fisik lingkungan: ukuran, bentuk, dan lokalitas.
2. Atribut organisasi: aplikasi kantor, aplikasi militer.
3. Model pengguna potensial
4. Keselamatan / keamanan / bahaya
c. Manajemen proyek
Bagaimana pengembangan sistem akan berjalan (dokumentasi sistem,
standar, prosedur untuk pengujian dan integrasi model, prosedur untuk
mengendalikan perubahan, asumsi / perubahan yang diharapkan).
d. Persyaratan Pengiriman dan Pemasangan Sistem
Contohnya: Hasil kerja, tenggat waktu, kriteria penerimaan, jaminan
kualitas, struktur dokumen / standar / pelatihan / manual / dukungan
dan pemeliharaan.
e. Kendala Fungsional
Mereka menggambarkan sifat-sifat yang diperlukan dari perilaku
sistem yang dijelaskan dalam persyaratan fungsional. Contoh dari
sifat-sifat ini adalah: Kinerja, efisiensi, waktu respons, keselamatan,
keamanan, keandalan, kualitas, dan ketergantungan.
f. Kendala Desain
Pengguna mungkin ingin agar perangkat lunak memenuhi persyaratan
tambahan tertentu. Kondisi-kondisi ini adalah: standar perangkat keras
dan perangkat lunak, perpustakaan dan sistem operasi tertentu yang
akan digunakan, dan masalah kompatibilitas.
g. Persyaratan Protokol Data dan Komunikasi
 Mereka adalah: input, output, interface, dan protokol komunikasi
antara sistem dan lingkungan.

3) Hal yang Tidak Boleh Ada Dalam SRS

SRS tidak boleh menangani masalah desain seperti: (a)
mempartisi perangkat lunak ke dalam modul, (b) menugaskan fungsi ke
modul, (c) menjelaskan aliran informasi dan kontrol antar modul, dan (d)
memilih data struktur. Namun ada kasus khusus di mana pertimbangan
desain tertentu seperti kesesuaian dengan standar, standar kinerja, dll, harus
ditentukan dalam SRS sebagai kendala desain.
Juga, SRS tidak boleh mencakup informasi persyaratan proyek
seperti biaya proyek, jadwal pengiriman, prosedur pelaporan, metode
pengembangan perangkat lunak, jaminan kualitas, kriteria validasi dan
verifikasi, dan prosedur penerimaan. Mereka umumnya ditentukan dalam
dokumen lain seperti rencana pengembangan perangkat lunak, rencana
jaminan kualitas perangkat lunak, dan pernyataan kerja.

4) Struktur Dari SRS

Struktur dari sebuah SRS memuat semua informasi umum yang dibutuhkan
dalam menganalisis kebutuhan perangkat lunak, sebagai berikut :
1. Pendahuluan
1.1 Tujuan

1.2 Cakupan

1.3 Definisi, Akronim, dan Singkatan.

1.4 Referensi

1.5 Gambaran
 2. Deskripsi Umum

2.1 Perspektif produk

2.2 Fungsi Produk

2.3 Karakteristik Pengguna

2.4 Kendala

2.5 Asumsi dan Ketergantungan

3. Persyaratan Khusus
Ada beberapa varian untuk Bagian 3. Bagian ini dapat disusun
berdasarkan :
(a) mode, (b) kelas pengguna, (c) objek, (d) fitur, (e) stimulus, (f)
hierarki fungsional, dan (g) banyak organisasi.
 Templat SRS Bagian 3 Disusun berdasarkan Mode: Versi 1
 Templat SRS Bagian 3 Disusun oleh Mode: Versi 2
 Templat SRS Bagian 3 Diorganisir oleh Kelas Pengguna
 Templat SRS Bagian 3 Diorganisasikan oleh Objek
 Templat SRS Bagian 3 Diorganisasikan berdasarkan Fitur
 Templat SRS Bagian 3 Diorganisir oleh Stimulus
 Templat SRS Bagian 3 Diorganisir oleh Hierarki Fungsional
 Templat SRS Bagian 3 Menampilkan Beberapa Organisasi

5) VALIDASI DOKUMEN KEBUTUHAN

Dokumen kebutuhan perlu divalidasi untuk menunjukkan bahwa
dokumen itu benar-benar mendefinisikan sistem yang diinginkan klien.
Biaya spesifikasi yang tidak memadai bisa sangat tinggi. Biasanya
kebutuhan harus diperiksa dari sudut pandang pelanggan dan pengembang.
 Boehm (1984) dan banyak lainnya telah memberikan metode yang
berbeda untuk memvalidasi persyaratan perangkat lunak. Ini adalah
sebagai berikut:
a. Dibaca oleh orang lain selain penulis.
b. Membangun skenario.
c. Tinjauan persyaratan untuk mendeteksi ketidaklengkapan,
ketidakkonsistenan, dan ketidaklayakan.
d. Alat otomatis untuk memeriksa konsistensi ketika persyaratan ditulis
dalam bahasa formal.
e. Simulasi yang memeriksa persyaratan kritis non-fungsional, seperti
'waktu'.

6) IDENTIFIKASI DAN MENGUKUR KUALITAS DI SRS

Berdasarkan survei dari sejumlah artikel tentang kualitas SRS, Davis, et
al. (1997) telah mendata 24 atribut kualitas untuk SRS (Tabel 6.10), yang
menyarankan bagaimana mendefinisikan dan mengukurnya dalam SRS
sehingga dapat digunakan untuk mengevaluasi kualitas SRS. Dalam hal-
hal berikut, kita mendefinisikan dan memberikan langkah-langkah kualitas
dari 12 atribut- atribut kualitas.
Asumsikan berikut:
nr : sejumlah persyaratan dalam SRS
R : himpunan semua persyaratan
nf : Jumlah kebutuhan fungsional di SRS
R f: himpunan semua persyaratan fungsional
nnf: sejumlah persyaratan non-fungsional di SRS
Rnf: himpunan semua persyaratan non-fungsional