terimakasih

1. Rekayasa PerangkatLunak
(Software Engineering)
Graha Prakarsa,ST.MT.
SekolahTinggiTeknologiBandung
1
Memahami pengertian kebutuhan perangkat
lunak.
Memahami apa yang dimaksud dengan analisis
kebutuhandan tahappelaksanaannya.
Mengetahui arti, fungsi, dan sistematika
penulisan dokumen Spesifikasi Kebutuhan
PerangkatLunak.
2
Kebutuhan perangkat lunak  kondisi atau
kemampuan yang harus dimiliki oleh perangkat
lunak untuk memenuhi apa yang disyaratkan atau
diinginkan pemakai.
Tiga buah jeniskebutuhan perangkat lunak
 Kebutuhan fungsional (functionalrequirement)
 Kebutuhan antarmuka (interfacerequirement)
 Kebutuhan unjukkerja(performancerequirement)
3
Disebut juga kebutuhan operasional, yaitu kebutuhan yang
berkaitan dengan fungsi atau proses transformasi yang
harus mampu dikerjakanoleh perangkatlunak.Contoh:
 Perangkat lunak harus dapat menyimpan semua rincian
data pesananpelanggan.
 Perangkat lunak harus mampu mencetak laporan
penjualansesuai periode yang diinputkan.
 Perangkat lunak harus mampu menyajikan informasi jalur
pengiriman terpendek.
4
1

2. Kebutuhan antarmuka yang menghubungkan perangkat
lunak dengan elemen perangkat keras, perangkat lunak lain,
ataubasis data.Contoh:
 Akses ke basis data menggunakan ODBC (Open Data Base
Connectivity).
 Perangkat untuk memasukkan data menggunakan
keyboard, mouse, danscanner.
5
Kebutuhan yang menetapkan karakteristik unjuk kerja yang
harus dimiliki oleh perangkat lunak, seperti kecepatan,
ketepatan, ataufrekuensi. Contoh:
 Waktu tanggap penyajian informasi maksimal selama satu
menit.
 Perangkat lunak harus mampu mengolah data sampai 1
juta record untuk setiap transaksi.
 Perangkat lunak harus dapat digunakan secara multi user
sesuai otoritas yang diberikan kepada masing‐masing
pemakai.
6
Proses mempelajari kebutuhan pemakai untuk
mendapatkan definisi kebutuhan sistem atau
perangkat lunak (IEEE, 1993).
Proses untuk menetapkan fungsi dan unjuk kerja
perangkat lunak, menyatakan antarmuka perangkat
lunak dengan elemen‐elemen sistem lain, dan
menentukan kendala yang harus dihadapi oleh
perangkat lunak (Pressman, 2001).
7
Pendefinisian kebutuhan yang baik dapat menjadi faktor
sukses pelaksanaan pengembangan perangkat lunak.
Sebaliknya akan menyebabkan banyak kegagalan. Menurut
hasil survey DeMarco, 56% kegagalan proyek perangkat
lunak adalah karena ketidaklengkapan pendefinisian
kebutuhan.
Menurut Davis (1993) Produk perangkat lunak yang tidak
sempurna akan dihasilkan karena kesalahan pada saat
menentukan spesifikasi kebutuhan. Jika kesalahan tersebut
diketahui di akhir siklus hidup pengembangan, usaha untuk
memperbaikinya akan sangat mahal (sekitar 82% dari total
biayaperbaikan).
8
2

3. the real problem
correct erroneous
specification specification
Requirements
specification
Design
correct
design
erroneous
design
design based
on erroneous
specification
correct
program
programming
error
program based
on erroneous
design
program based
on erroneous
specification
Implementation
Testing
correct
functions
correctable
errors
uncorrectable
errors
hidden
errors
imperfect program
products
9
Perangkat lunak yang dihasilkan tidak akan memenuhi
kebutuhan pemakai yang sebenarnya.
Intepretasi kebutuhan yang berbeda‐beda sehingga dapat
menyebabkan ketidaksepakatan antara pelanggan dan
pengembang, menyia‐nyiakan waktu dan biaya serta
mungkin akan menimbulkan perkara hukum.
Pengujian kesesuaian perangkat lunak dengan kebutuhan
yang dimaksud tidak akan mungkin dilaksanakan dengan
benar.
Waktu dan biaya akan terbuang percuma untuk membangun
perangkat lunakyang salah.
10
Tahap kebutuhanperangkat lunak dimulai dengan (Davis, 1993):
Adanya masalah yang membutuhkanpenyelesaian:
 orientasi aplikasi, misalnyainventory
 orientasibisnis, misalnya produk baru, peramalanpendapatan
 orientasipeningkatan produk, misalnya pemeliharaan
Munculnya ideuntuk membuat sebuah perangkat lunak baru.
Tahap kebutuhan berakhir apabila deskripsi lengkap dari
perilaku eksternal perangkat lunak yang akan dibangun sudah
didapat, termasuk dokumentasi seluruh antarmuka perangkat lunak
dengan lingkungannya (perangkat keras, perangkat lunak lain,
pemakai) yang dicatat dalam Spesifikasi Kebutuhan Perangkat Lunak
(SKPL).
11
1. Mempelajaridan memahami persoalan
2. Mengidentifikasi kebutuhanpemakai
3. Mendefinisikankebutuhan perangkat lunak
4. Membuat dokumen spesifikasi kebutuhan
5. Mengkajiulang (review)kebutuhan
12
3

4. Siapa pemakaiyang akan menggunakan perangkatlunak?
Dimana perangkatlunakakan digunakan?
Pekerjaan apa dari pemakai yang akan dibantu oleh
perangkatlunak?
Dari dan sampai mana cakupan pekerjaan tersebut, dan
bagaimana mekanismepelaksanaannya?
Apa yang menjadi kendala atau keterbatasannya dilihat dari
sisi teknologi yang akan digunakan atau dari sisi hukum dan
standar?
13
Cara yangdigunakan:
wawancara denganpemakai
observasi ataupengamatanlapangan
Kuesioner
mempelajari referensi atau dokumen‐dokumen yang
digunakan, seperti dokumen hasil analisis dan perancangan
sistem
Hasil pemahaman masalah tersebut selanjutnya digambarkan
dalam bentuk model‐model tertentu sesuai dengan jenis
masalahnya. Sebagai contoh, untuk masalah bisnis dapat
menggunakanflowmap ataubusiness use case.
14
Tahap identifikasi kebutuhan pemakai (user requirement) ini pada
prakteknya dilaksanakan bersamaan dengan pemahaman masalah. Cara
yang digunakan pun relatif sama. Hanya saja, substansi yang ditanyakan
biasanya adalah:
 Dataatau informasiapa yang akan diproses?
 Fungsiapa yang diinginkan?
 Perilakusistem apa yang diharapkan?
 Antarmuka apa yang tersedia (user interfaces,hardware interfaces,
softwareinterfaces, dan communicationsinterfaces)?
Untuk dapat menangkap kebutuhan pemakai dengan baik diperlukan
kesamaan persepsi dengancara:
 Komunikasidan brainstormingyang intensif.
 Prototype perangkatlunak,atau screensnapshot.
 Dataatau dokumen yang lengkap.
15
Saat mengidentifikasi kebutuhan pemakai, informasi yang
diperoleh belum terstruktur. Pemakai akan mengungkapkan apa
yang dibutuhkannya dengan bahasa sehari‐hari yang biasa
digunakan pemakai. Sebagai contoh, ungkapan kebutuhan
pemakaidi BagianAkuntansi, misalnya:
 saya ingin data yang dimasukkan oleh Bagian Penjualan bisa
langsung dijurnal.
 informasineraca bisa saya lihat kapan saja.
Pada tahap ini, kebutuhan pemakai yang belum terstruktur
tersebut dianalisis, diklasifikasikan, dan diterjemahkan menjadi
kebutuhan fungsional, antarmuka, dan unjuk kerja perangkat
lunak.
16
4

5. ”
Sebagai gambaran, kebutuhan “data yang dimasukkan oleh Bagian Penjualan
dapat langsung dijurnal setelah dianalisis, diklasifikasikan, dan
diterjemahkan,mungkinmemberikanhasil:
1. Kebutuhan fungsional:
▪ entrydan rekamdata transaksipenjualan.
▪ retrieve nilai transaksi penjualan untuk periode tertentu (sesuai periode
yang diinputkanmelaluikeyboard).
▪ rekam nilai akumulasi transaksi penjualan periode tertentu ke jurnal
umumberikutaccountpasangannya(kas).
2. Kebutuhanantarmuka:
▪ antarmukapemakaiuntukmerekamdata penjualan.
▪ antarmuka pemakai untuk menyajikan dan menjurnal informasi nilai
transaksipenjualanperiode tertentu.
▪ jaringan lokal untuk menghubungkan perangkat lunak aplikasi di Bagian
Penjualandenganperangkatlunak aplikasi di BagianAkuntansi.
17
3. Kebutuhan unjukkerja:
▪ ada otoritas pemakaianperangkat lunak dan akses data.
▪ proses jurnal hanya dapat dilakukan sekali setelah data
transaksi penjualandirekam.
Selanjutnya, kebutuhan tersebut diubah menjadi model atau
gambar tertentu dengan memanfaatkan teknik analisis dan alat
bantu tertentu. Sebagai gambaran, kebutuhan fungsional dapat
dimodelkan denganmenggunakan:
 Data Flow Diagram, kamus data, dan spesifikasi proses jika
menggunakan teknikterstruktur.
 Diagram Use Case dan skenario sistem jika menggunakan
pendekatanobjek.
18
Semua kebutuhan yang telah didefinisikan selanjutnya
dibuatkan dokumentasinya, yaitu Spesifikasi Kebutuhan
Perangkat Lunak (SKPL) atau Software Requirements
Specification (SRS).
SKPL yang dibuat harus dapat menyatakan secara lengkap
apa yang dapat dilakukan oleh perangkat lunak, termasuk
deskripsilengkap darisemua antarmukayang digunakan.
SKPL bisa terdiri dari banyak dokumentasi yang saling
melengkapi.
19
Proses untuk memeriksa (validasi) SKPL apakah
sudah konsisten, lengkap, dan sesuai dengan apa
yang diinginkanpemakai.
Proses ini mungkin dilakukan lebih dari satu kali,
dan sering kali muncul kebutuhan‐kebutuhan baru
daripemakai.
Untuk itu, diperlukan negosiasi antara pihak
pengembang dengan pemakai sesuai prinsip “win‐
win solution” sampai kebutuhan tersebut dapat
disepakati kedua belah pihak.
20
5

6. SKPL adalah dokumen yang berisi pernyataan
lengkap dari apa yang harus dilakukan atau
dipenuhi oleh perangkat lunak, tanpa menjelaskan
bagaimana hal tersebut dilaksanakan oleh
perangkat lunak.
Selain itu, SKPL pun berisi deskripsi lengkap dari
semua antarmuka yang ada dalam perangkat lunak.
21
Sarana komunikasi antara pelanggan, pemakai,
analis,dan perancang perangkat lunak.
Dasar untuk merencanakan dan melaksanakan
pengujian sistem.
Acuan untuk melakukan perbaikan atau
pengubahan perangkatlunak.
22
Memastikan kesamaan antara kebutuhan untuk pengembangan
dengan kebutuhanyang ditulis dalam dokumen.
Mendefinisikan kerangka kerja bersama untuk proses‐proses
pengembangan perangkatlunak.
Memperjelas peran dan antarmuka bagi para pihak yang terlibat
dalamproses‐proses pengembangan perangkat lunak.
Memperjelas jenis dan isi daridokumen.
Mengenali tugas‐tugas, tahapan‐tahapan, baselines, aktivitas kaji
ulang, dandokumentasinya.
Belajar dari pendekatan praktis yang diterapkan di dunia industri.
Menghilangkan jebakan‐jebakan dan persoalan‐persoalan seperti
yang dialami di masa lalu.
23
Memberikan penjelasan yang berlebih‐lebihan dan berulang‐
ulang sehingga menjaditidakjelas.
Menggunakan istilah secara tidakkonsisten.
Menyatakan keterukuran kebutuhan secara tidak jelas,
misalnya dengan menggunakan kata‐kata: minimal,
maksimal, optimial, cepat, user‐friendly, mudah, sederhana,
normal, efisien, fleksibel, dan/atau, dan lain‐lain, atau dan
sebagainya.
Menuliskan “mimpi‐mimpi”, yaitu hal‐hal yang tidak akan
dapatdilakukanoleh perangkat lunak.
24
6

7. 1. Benar
2. Tidak bias(unambiguous)
3. Lengkap
4. Dapat diverifikasi
5. Konsisten
6. Dapatdipahami oleh pelanggan
7. Dapatdimodifikasi
8. Dapat ditelusuri
9. Mempunyai keterangan(annotated)
10. Ringkas
11. Terorganisasi
25
1. Pemakai
2. Pelanggan
3. AnalisSistem (System Engineer)
4. SoftwareEngineer
5. Pemrogram
6. Test IntegrationGroup
7. MaintenanceGroup
8. TechnicalSupport
9. Staf dan ClericalWork
26
1. PENDAHULUAN
1. Kegunaan
2. Ruang Lingkup
3. Definisi,Akronim,danSingkatan
4. Referensi
5. Ikhtisar
2. DESKRIPSI UMUM
1. Perspektif Produk
2. Fungsi Produk
3. KarakteristikPemakai
4. Batasan‐batasan
5. Asumsi danKetergantungan
3.KEBUTUHAN RINCI
1. Kebutuhan AntarmukaEksternal
1. AntarmukaPemakai
2. Antarmuka PerangkatKeras
3. Antarmuka PerangkatLunak
4. AntarmukaKomunikasi
2. KebutuhanFungsional
1. Deskripsi KebutuhanFungsional
2. Diagram Konteks
3. Diagram AliranData
1. DiagramAliran Data Proses 1
2. DiagramAliran Data Proses 2
.
.
3.2.3.n Diagram Aliran Data Proses n
4. KamusData
1. Tempat PenyimpananData
2. Aliran Data
5. Spesifikasi Proses
1. Proses1
2. Proses2
.
.
3.2.5.mProsesm
3. KebutuhanPerformansi
4. KendalaPerancangan
5. Atribut Sistem PerangkatLunak
6. KebutuhanLain
27
Kebutuhan perangkat lunak dapat diartikan sebagai sesuatu
(kemampuan, kondisi, kriteria) yang harus ada atau dipenuhi oleh
perangkat lunak. Ada tiga jenis kebutuhan, yaitu fungsional, antarmuka,
dan unjukkerja.
Kebutuhan perangkat lunak didefinisikan melalui proses analisis
kebutuhan. Ada serangkaian tahap yang harus dilaksanakan sebelum
dapat mendefinisikan kebutuhan ini. Hasil dari proses analisis kebutuhan
dapat menjadi faktor sukses pelaksanaan pengembangan perangkat
lunak.
Kebutuhan perangkat lunak ditulis secara sistematis dalam suatu
dokumen yang disebut SKPL, sehingga dapat dijadikan acuan oleh
pemakai dan pengembang saat dan setelah pelaksanaan pembuatan
perangkat lunak. Untuk itu, ada beberapa hal, seperti atribut dan
sistematika, yang harus diperhatikan untuk dapat menuliskan SKPL yang
baik.
28
7

8. AnalisisTerstruktur
29
Setelah UTS kumpulkan fungsi‐fungsi/modul‐modul perangkat
lunakapa saja yang nanti akan dikembangkan.
Tugas dikumpulkan dalam bentuk power point (3‐6 slide sudah
cukup).
Tugas dikumpulkan melalui email hari minggu tanggal 13‐12‐2015
jam 24.00ke “gprakarsa@gmail.com”
Tanggal 14‐12‐2015 (pertemuan setelahUTS) dipresentasikan.
Isi tugas:
1. Nama dan anggota Kelompok, contoh: PASTI JADI CORP.
2. Kumpulan fungsi/modul, contoh: modul input data penjualan &
pembelian,pencetakan laporan…., dll.
Intinya menceritakan software‐nya nanti memiliki fungsi apa saja.
30
Kelompok 1:Restoran (Ahmad)
Kelompok 2: Hotel (Dejan)
Kelompok 3:Bioskop (Dede)
31
8