A.

SIKLUS SOLUSI RPL

• Memahami dan mendefinisikan masalah

Bagian ini merupakan bagian yang sangat penting karena menjadi awal dari seluruh
proses pemecahan masalah. Tujuan pada bagian ini adalah memahami masalah dengan
baik dan menghilangkan bagian bagian yang dirasa kurang penting.

• Membuat rencana untuk pemecahan masalah

Pada bagian ini ada dua kegiatan penting yaitu :
a) mencari berbagai cara penyelesaian yang mungkin diterapkan
b) membuat rencana pemecahan masalah

Penyelesaian suatu masalah biasanya tidak hanya satu tapi mungkin bisa beberapa macam.
Sebagai ilustrasi, apabila kita berada di kota Surabaya dan ingin pergi ke Jakarta, maka banyak
cara yang mungkin bisa dilakukan, misalnya kita bisa menempuh dengan angkutan darat, laut
atau udara.

Dengan angkutan darat kita bisa menggunakan kereta api, bus atau angkutan yang lain. Jalurnya
pun kita bisa lewat jalur utara, tengah atau selatan. Jadi banyak sekali cara penyelesaian yang
bisa kita kembangkan. Masing-masing mempunyai karakteristik sendiri-sendiri. Dari sekian
banyak penyelesaian ini kita harus memilih satu yang berdasarkan persyaratantertentu
merupakan cara yang paling baik untuk menyelesaikan permasalahan. Setelah terpilih, maka kita
dapat membuat rencana kasar (outline) penyelesaian masalah dan membagi masalah dalam
bagian-bagian yang lebih kecil. Rencana kasar (outline) penyelesaian masalah hanya berisi
tahapan-tahapan utama penyelesaian masalah.

• Merancang dan menerapkan rencana untuk memperoleh cara penyelesaian

Pada bagian ini rencana kasar penyelesaian masalah diperbaiki dandiperjelas dengan
pembagian dan urutan rinci yang harus ditempuh dalam penyelesaian masalah.

• Memeriksa dan menyampaikan hasil dari pemecahan masalah

Bagian ini bertujuan untuk memeriksa apakah akurasi (ketepatan) hasil dari cara yang
dipilih telah memenuhi tujuan yang diinginkan. Selain itu juga untuk melihat bagaimana
daya guna dari cara yang dipilih yang dipilih.
 B. Proses Rekayasa Kebutuhan

Feasibility Requirements
study elicitation and
analysis
Requir ements
specification
Feasibility Requirements
report validation
System
models
User and system
requirements

Requirements
document

1. Feasibity study ( studi kelayakan )

Adalah sebuah analisa dan evaluasi dari proyek yang diusulkan untuk menentukan apakah
secara teksis layak, layak dalam perkiraan biaya dan [Link] proyek layak bila
sumber dan waktunya tidak terbatas.
Feasibility Report yaitu analisis yang mengevaluasi satu atau lebih langkah-langkah tindakan
potensial dan merekomendasikan bagaimana organisasi tersebut harus dilanjutkan.
Diperkirakan biaya, mengidentifikasi manfaat yang diharapkan memperkirakan berapa lama
proyek akan mengambil dan menguraikan kesulitan potensial.

2. Requirements Elicitation and Analysis (Analisis Kebutuhan)

Requirements Elicitation and Analysis adalah proses mengumpulkan dan memahami masalah
dan kegiatan yang berjalan. Pada proses ini biasanya dilakukan dengan observasi terhadap
lingkungan proyek yang akan digarap – termasuk fact gathering, wawancara pada pengguna
langsung atau para menajer, dan bisa juga dengan mempelajari alur kerja yang terjadi dari bisnis
proses yang berjalan.
System Models adalah sistem model konseptual yang menggambarkan dan mewakili
suatu sistem. Sebuah sistem terdiri dari beberapa pandangan seperti perencanaan,
persyaratan, desain, implementasi, penyebaran, struktur, perilaku, input data, dan data
tampilan output.

3. Requirements Specification
Adalah akibat langsung dari analisis kebutuhan dan dapat merujuk. Jika seluruh kegiatan
dan permasalah yang terjadi pada bisnis proses yang berjalan dimengerti dengan baik,
maka software developer akan menkonversikan ke dalam suatu bentuk laporan tertulis
yang berisi tentang semua definisi dan spesifikasi dari seluruh kebutuhan yang ada pada
bisnis proses yang ada.
User and Systems Requirements
      User requirement (kebutuhan pengguna)
Pernyataan tentang layanan yang disediakan sistem dan tentang batasan
batasan operasionalnya. Pernyataan ini dapat dilengkapi dengan
gambar/diagram yang dapat dimengerti dengan mudah.
      System requirement (kebutuhan sistem)
Sekumpulan layanan/kemampuan sistem dan batasan-batasannya yang ditulis
secara detil. System requirement document sering disebut functional
specification (spesifikasi fungsional), harus menjelaskan dengan tepat dan detil.
Ini bisa berlaku sebagai kontrak antara klien dan pembangun.
4. Requirements Validation
Adalah kepastian bahwa suatu produk, layanan, atau sistem memenuhi kebutuhan pelanggan
dan stakeholder lainnyadidentifikasi. Ini sering melibatkan penerimaan dan kesesuaian dengan
pelanggan eksternal. Setelah spesifikasi requirements berhasil dibuat, perlu dilakukan dua
usaha: Validation (validasi), yaitu proses untuk memastikan bahwa requirements yang benar
sudah ditulis.
Requirements Document (Dokumen Kebutuhan)
Dokumen kebutuhan merupakan pernyataan resmi dari apa yang dibutuhkan dari pembangun
sistem, berisi definisi dan spesifikasi requirement dan bukan dokumen desain. Sebisa mungkin
berupa kumpulan dari APA yang harus dikerjakan sistem, BUKAN BAGAIMANA system
mengerjakannya.

C. Proses Perancangan Perangkat Lunak

Requirements
specificatio n

Design activities

Architectural Interface Component Data Algorithm

Abstract
design design design structure design
specificatio n
design

Software Data
System Interface Component Algorithm
specificatio n structure
architecture specificatio n specificatio n specificatio n
specificatio n

Design products
Kegiatan-kegiatan proses perancangan adalah:
1. Perancangan arsitektural. Subsistem-subsistem yang membentuk sistem dan hubungan
mereka diidentifikasi dan didokumentasi.
2. Spesifikasi abstrak. Untuk setiap subsistem, spesifikasi abstrak dari layanan dan batas
operasinya harus ditentukan.
3. Perancangan interface. Untuk setiap subsistem, interface subsistem dirancang dan
didokumentasi. Spesifikasi interface ini harus sudah jelas karena memungkinkan subsistem
dipakai tanpa mengetahui operasi subsistem.
4. Perancangan komponen. Layanan dialokasikan pada komponen yang berbeda dan interface
komponen-komponen ini dirancang.
5. Perancangan struktur data. Struktur data yang dipakai pada implementasi sistem dirancang
secara rinci dan dispesifikasi.
6. Perancangan algoritma. Algoritma yang digunakan untuk memberikan layanan dirancang
secara rinci dan dispesifikasi.
 D. Validasi Perangkat Lunak

Unit
testing
Module
testing
Sub-system
testing
System
testing
Acceptance
testing

Component Integration testing User

testing testing

Tahap-tahap pengujian:

1. Pengujian unit. Komponen individual diuji untuk menjamin operasi yang benar. Setiap
komponen diuji secara independen.

2. Pengujian modul. Modul merupakan sekumpulan komponen yg berhubungan seperti kelas,

objek, tipe data abstrak, atau sekumpulan prosedur. Sebuah modul dapat diuji tanpa modul
sistem yang lain.

3. Pengujian sub sistem. Fase ini melibatkan pengujian sekumpulan modul yg telah
diintegrasikan menjadi sub sistem.

4. Pengujian sistem. Penemuan kesalahan akibat dari interaksi yg tidak diharapkan antara sub
sistem dan masalah interface sub sistem. Proses ini berhubungan dengan validasi bahwa sistem
telah memenuhi persyaratan fungsional dan non fungsionalnya.

5. Pengujian penerimaan. Sistem diuji dengan data yang dipasok oleh pelanggan sistem dan
bukan data uii simulasi.

E. Stage Pengujian Perangkat Lunak

Requirements System System Detailed

specification specification desig n design

System Sub-system Module and

Acceptance
integration integration unit code
test plan
test plan test plan and tess

Acceptance System Sub-system

Service
test integration test integration test
Tahapan Pengujian Perangkat Lunak

1. Pengujian Unit / Unit Testing

Unit Testing adalah metode verifikasi perangkat lunak di mana programmer menguji
suatu unit program layak untuk tidaknya dipakai. Unit testing ini fokusnya pada
verifikasi pada unit yang terkecil pada desain perangkat lunak (komponen atau modul
perangkat lunak). Karena dalam sebuah perangkat lunak banyak memiliki unit-unit
kecil maka untuk mengujinya biasanya dibuat program kecil atau main program)
untuk menguji unit-unit perangkat lunak. Unit-unit kecil ini dapat berupa prosedur
atau fungsi, sekumpulan prosedur atau fungsi yang ada dalam satu file jika dalam
pemrograman terstruktur, atau kelas, bisa juga kumpulan kelas dalam satu package
dalam PBO. Pengujian unit biasanya dilakukan saat kode program dibuat.

2. Pengujian Integrasi

Pengujian integrasi lebih pada pengujian penggabungan dari dua atau lebih unit pada
perangkat lunak. Pengujian integrasi sebaiknya dilakukan ssecara bertahap untuk
menghindari kesulitan penelusuran jika terjadi kesalahan error / bug.

3. Pengujian Sistem

Unit-unit proses yang telah diintegrasikan diuji dengan antarmuka yang sudah dibuat
sehingga pengujian ini dimaksud untuk menguji sistem perangkat lunak. Perlu diingat
bahwa pengujian sistem harus dilakukan secara bertahap sejak awal pengembangan,
jika pengujian hanya diakhir maka dapat dipastikan kualitas sistemnya kurang bagus.

4. Pengujian Penerimaan

Pengujian penerimaan perangkat lunak dilakukan oleh pengguna yang telah bekerja
sama dengan pembuat program guna untuk mengetahui secara langsung bagaimana
perangkat lunak yang telah dibuat dapat bekerja sebelum perangkat lunak yang dibuat
disebar luaskan. Pengujian penerimaan ini bertujuan untuk mengetahui kepuasan
pengguna atau user.