MAKALAH

“ANALISIS KEBUTUHAN PERANGKAT LUNAK”

Dikumpulkan Untuk Melengkapi Tugas Kelompok

Mata Kuliah : Rekayasa Perangkat Lunak

Oleh :
Okta Ayu Wulandari Putri
Ulfi Silsilia
Khairul Mukmin
Ikhwanuddin

PENDIDIKAN TEKNOLOGI INFORMASI

STKIP PGRI SITUBONDO
TAHUN PELAJARAN 2017/2018
KATA PENGANTAR
Puji syukur kami panjatkan kehadirat Allah SWT yang telah memberikan rahmat serta karunia-Nya
sehingga saya berhasil menyelesaikan makalah ini yang alhamdulillah tepat pada waktunya yang
makalah
yang membahas “Rekayasa Perangkat Lunak”. Makalah ini berisikan tentang yang awal yang
bermunculan dengan pengertian dimana khususnya membahas “Rekayasa Perangkat Lunak” yang
digunakan sangat luas dan berbagai forum publik lainnya.
Diharapkan makalah ini dapat memberikan informasi kepada kita semua tentang “Rekayasa Perangkat
Lunak”. Saya menyadari bahwa makalah ini masih jauh dari sempurna, oleh karena itu kritik dan saran
dari semua pihak yang bersifat membangun selalu kami harapkan demi kesempurnaan makalah ini.
Akhir kata, kami sampaikan terima kasih kepada semua pihak yang telah berperan serta dalam
penyusunan makalah ini dari awal sampai akhir. Semoga Allah SWT senantiasa meridhai segala usaha
kita. Amin.
Tangerang, 23 April 2016
Penyusun
 BAB I
PENDAHULUAN

1.1. Latar Belakang

Rekayasa perangkat lunak (RPL, atau dalam bahasa Inggris: Software Engineering
atau SE) adalah satu bidang profesi yang mendalami cara-cara pengembangan perangkat
lunak termasuk pembuatan, pemeliharaan, manajemen organisasi pengembanganan perangkat
lunak dan manajemen kualitas. IEEE Computer Society mendefinisikan rekayasa perangkat
lunak sebagai penerapan suatu pendekatan yang sistematis, disiplin dan terkuantifikasi atas
pengembangan, penggunaan dan pemeliharaan perangkat lunak, serta studi atas pendekatan-
pendekatan ini, yaitu penerapan pendekatan engineering atas perangkat lunak.
Rekayasa Perangkat Lunak adalah pengubahan perangkat lunak itu sendiri guna
mengembangkan, memelihara, dan membangun kembali dengan menggunakan prinsip
reakayasa untuk menghasilkan perangkat lunak yang dapat bekerja lebih efisien dan efektif
untuk pengguna.serta para software engineeruntuk membuat dokumentasi perangkat lunak
yang sistematis.
Pada penelitian sebelumnya, telah dikembangkan sebuah perangkat generator
dokumen perangkat lunak secara umum (Roth, 2009), dokumen semantik perangkat lunak
(Arantes dan Falbo, 2010) serta dokumen arsitektural perangkat lunak (Riva dan Yang, 2002).
Namun metode yang diberikan pada perangkat tersebut terlalu kompleks untuk para
mahasiswa yang baru belajar RPL. Belum ada perangkat yang menyediakan sebuah
pembuatan dan pengelolaan dokumen RPL secara sederhana dan mudah digunakan oleh para
mahasiswa.Harapannya dengan adanya perangkat sederhana ini, mahasiswa dapat terbiasa
mendokumentasikan proses rekayasa perangkat lunak dengan baik dan benar.
Hal yang akan disajikan dalam makalah ini adalah analisis dan rancangan sebuah
prototipe manajemen dokumentasi RPL sebagai sarana kolaborasi antara dosen dan
mahasiswa. Perangkat lunak yang dikembangkan harus dapat digunakan mahasiswa untuk
mencetak dokumen dari proses RPL yang mereka lakukan. Perangkat lunak ini juga harus
mampu mendaftarkan mahasiswa sebagai member yang mengelola dokumen RPL mereka
masing-masing. Sedangkan bagi dosen, perangkat lunak ini harus mampu membuat skema
dan proyek dokumentasi RPL dan mengubahnya sesuai kebutuhan.
1.2. Rumusan Masalah

1. Apa yang dimaksud dengan analisis kebutuhan perangkat lunak ?

2. Apa yang dimaksud dengan kebutuhan (Requirement) ?
3. Apa saja prinsip-pinsip analisis ?
4. Apa yang dimaksud dengan prototyping perangkat lunak ?

1.3. Tujuan

1. Menjelaskan tentang pengertian analisis kebutuhan perangkat lunak.

2. Menjelaskan tentang pengertian kebutuhan (Requirement).
3. Menjelaskan tentang prinsip-pinsip analisis.
4. Menjelaskan tentang pengertian prototyping perangkat lunak.
 BAB II

PEMBAHASAN

2.1 Pengertian Analisis Kebutuhan Perangkat Lunak

Analisis kebutuhan perangkat lunak (software requirements analysis) merupakan

aktivitas awal dari siklus hidup pengembangan perangkat lunak. Untuk proyek-proyek
perangkat lunak yang besar, analisis kebutuhan dilaksanakan setelah aktivitas sistem
information engineering dan software project planning. Tahap analisis adalah tahapan
pengumpulan kebutuhan-kebutuhan dari semua elemen sistem perangkat lunak yang akan di
bangun. Pada tahap ini dibentuk spesifikasi kebutuhan perangkat lunak, fungsi perangkat
lunak yang dibutuhkan, performansi (unjuk kerja) sistem perangkat lunak, penjadwalan
proyek, identifikasi sumber daya (manusia, perangkat keras dan perangkat lunak yang
dibutuhkan) dan taksiran biaya pengembangan perangkat lunak. Kegunaan analisis adalah
untuk memodelkan permasalahan dunia nyata agar dapat dimengerti. Permasalahan dunia
nyata harus dimengerti dan dipelajari supaya spesifikasi kebutuhan perangkat lunak dapat
diungkapkan. Tujuan aktivitas ini adalah untuk mengetahui ruang lingkup produk (product
space) dan pemakai yang akan menggunakannya. Analisis yang baik akan mengungkapkan
hal-hal yang penting dari permasalahan, dan mengabaikan yang tidak penting.

Setiap metode analisis mempunyai pandangan yang berbeda. Tetapi pada dasarnya
semua metode analisis memiliki prinsip analisis yang sama, yaitu :
1. Menggambarkan domain informasi masalah.
2. Mendefinisikan fungsi perangkat lunak.
3. Menghasilkan model yang menggambarkan informasi, fungsi dan kelakuan yang
dibagi secara rinci pada sebuah model lapisan (hirarki).
4. Informasi pokok pada tahap analisis memudahkan tahap implementasi yang
lebih rinci.

Tujuan tahap analisis adalah :

1. Menjabarkan kebutuhan pemakai.
2. Meletakkan dasar-dasar untuk tahap perancangan perangkat lunak.
3. Mendefinisikan semua kebutuhan pemakai sesuai dengan lingkup kontrak yang
disepakati kedua belah pihak (pengembang dan pengguna).
 2.2 Kebutuhan (Requirement)
Pengertian Kebutuhan Menurut arti kamus, kebutuhan adalah sesuatu yang
diminta, sesuatu yang dibutuhkan. Sedangkan menurut IEEE (The Institute of Electrical
and Electronics Engineers) kebutuhan adalah :
 Kondisi atau kemampuan yang diperlukan pemakai untuk
menyelesaikan suatu persoalan, atau untuk mencapai sebuah objek.
 Kondisi atau kemampuan yang harus dipenuhi oleh sistem, dalam arti
memenuhi kontrak, standar, spesifikasi atau dokumen formal lain yang
diinginkan.

Tahap kebutuhan akan perangkat lunak dimulai dengan:

1. Dikenalinya adanya sebuah permasalahan yang membutuhkan sebuah

penyelesaian. Identifikasi sebuah permasalahan mungkin dapat dilakukan
dengan berorientasi pada aplikasi, berorientasi pada bisnis, atau berorientasi
pada kenaikan produktivitas (product improvement oriented).

2. Munculnya ide untuk membuat sebuah perangkat lunak baru (sebagai

sebuah kemajuan).

Ada dua jenis kebutuhan:

1. Behavi
oral
Adalah apa yang dilakukan oleh sistem (input dan output dari dan ke sistem),
hubungan informasi antara input dan output sehingga menghasilkan sebuah
fungsi transformasi.
2. Non-behavioral
Mendefinisikan atribut sistem yang terkait untuk membentuk pekerjaan
tersebut. Termasuk deskripsi lengkap tentang efisiensi, keamanan (security),
rehability maintenability (bagaimana perawatan untuk sistem), dan portability
(bisa dipindahkan dari satu perangkat keras ke perangkat keras lainnya).

2.3 Prinsip – Prinsip Analisis

Lebih dari dua decade terakhir, para peneliti mengidentifikasi masalah – masalah
analisis dan penyebab – penyebabnya, serta mengembangkan berbagai notasi pemodelan
dan serangkaian penelitian yang sesuai untuk menanggulanginya. Masing – masing
metode analisis memiliki titik pandang yang unik. Tetapi semua metode analisis
dihubungkan oleh serangkaian prinsip operasional:
 Dominan informasi dari suatu masalah harus direpresentasikan dan
dipahami.
 Fungsi – fungsi yang akan dilakukan oleh perangkat lunak harus di
definisikan.
 Tingkah laku perangkat lunak (sebagai suatu urutan kejadian eksternal)
harus diwakilkan.
 Model – model yang menggambarkan informasi, fungsi, dan tingkah laku
harus dipecah – pecah dalam suatu cara yang membongkar suatu detail dalam
bentuk lapisan (atau hirarki).
 Proses analisis harus bergerak dari informasi dasar ke detail
implementasi.

Dengan mengaplikasikan prinsip-prinsip tersebut, analisis mendekati suatu masalah

secara sistematis. Domain informasi diuji sehingga fungsi itu dapat di pahami secara lebih
lengkap. Model-model digunakan sehingga karakteristik fungsi dan tingkah laku dapat
dikomunikasikan dengan cara yang rapi. Pembagian diterapkan untuk mengurangi
keruwetan. Pandanagan esensial dan implementasi dari perangkat lunak diperlukan untuk
mengakomodasi batasan logis yang dibebankan oleh persyaratan pemrosesan dan batasan
fisik yang dibebankan oleh elemen system yang lain. Sebagai tambahan untuk prinsip
analisis operasional tersebut, Davis [DAV95a] mengusulkan serangkaian 5 prinsip
panduan untuk “rekayasa persyaratan”.

Mengembangkan prototype yang memungkinkan seorang pemakai memahami bagaimana

interaksi manusia dengan mesin terjadi. Karena persepsi mengenai kualitas prangkat
lunak sering di dasarkan pada persepsi “friendliness” interface, maka prototyping (dan
terasi yang dihasilkan) sangatlah dianjurkan.

1. Merekam asal dan alas an untuk setiap persyaratan. Hal ini merupakan
langkah pertama dalam membangun kemampuan penelusuran kembali ke
pelanggan.

2. Menggunakan pandangan persyaratan bertingkat. Pembangunan data,

fungsional, dan model tingkah laku member perekayasa perangkat lunak tiga
 pandangan berbeda. Hal ini mengurangi kemungkinan bahwa inkonsistensi
akan diketahui.

3. Memprioritaskan persyaratan. Batas waktu yang tegas dapat

menghalangi implementasi setiap persyaratan perangkat lunak. Bila model
proses inkremental (Bab2) diaplikasikan, maka persyaratan yang disampaikan
dalam inkremental pertama harus di identifikasi.

4. Berusaha mengurangi ambiguitas. Karena sebagian besar persyaratan di

gambarkan dalam bahasa natural, kemungkinan untuk terjadinya ambiguitas
selalu ada. Penggunaan kajian teknis formal merupakan satu-satunya cara
untuk mengurangi ambiguitas tersebut.

5. Perekayasa perangkat lunak yang mempercayai prinsip tersebut akan

dapat lebih mengembangkan spesifikasi perangkat lunak yang kemudian akan
menjadi dasar yang kuat bagi desain.

1. Domain Informasi
Semua aplikasi perangkat lunak secara kolektif dapat disebut data processing.
Menarik bahwa istilah itu berisi sebuah kunci ke pemahaman terhadap persyaratan
perangkat lunak. Perangkat lunak dibangun untuk memproses data, menstraformasi
data dari bentuk yang satu kebentuk yang lain, yaitu untuk menerima input,
memanipulasinya dengan berbagai cara, dan menghasilkan output. Pernyataan
mendasar dari sasaran ini benar bila kita membangun perangkat lunak batch untuk
system daftar gaji atau perangkat lunak real-time embedded untuk mengontrol aliran
bahan bakar ke mesin kendaraan bermotor.

Tetapi sangat penting untuk dicatat bahwa perangkat lunak juga memproses event.
Event mewakili banyak aspek dari control system dan tidak lebih daripada data
Boolean
baik on atau off, true or false, there or not there. Sebagai contoh, sensor tekanan
mendeteksi bahwa tekanan melampaui batas nilai aman dan mengirimkan sebuah
sinyal alarm ke monitoring perangkat lunak. Sinyal alarm tersebut merupakan suatu
event yang mengontrol tingkah laku system. Dengan demikian, data (bilangan,
karakter, citra, suara, dll) dan control (kejadian), keduanya ada pada domain informasi
dari suatu masalah.

Prinsip analisis operasional yang pertama membutuhkan suatu pengujian domain

informasi. Domain informasi berisi tiga pandangan yang berbeda dari data dan control
ketika masing-masing dip roses oleh program computer:
a. Muatan dan hubungan informasi
b. Aliran informasi
c. Struktur informasi

Untuk benar-benar memahami domain informasi, masing-masing dari pandangan

tersebut harus diperhatikan. Muatan Informasi mewakili data dan objek control
individual yang terdiri dari beberapa kumpulan informasi yang lebih besar yang di
transformasikan oleh perangkat lunak. Misalnya, objek data paycheck merupakan
sebuah gabungan dari sejumlah data yang penting : nama pembayar, jumlah bersih
yang dibayarkan, pembayaran keseluruhan, potongan, dan seterusnya. Demikianlah,
muatan dari paycheck ditentukan oleh atribut-atribut yang dibutuhkan untuk
membuatnya. Dengan cara yang sama, muatan dari suatu objek control yang disebut
status system dapat dibatasi oleh sebuah string dari banyak bit. Masing-masing bit
mewakili jenis informasi yang berbeda yang menunjukkan apakah perangkat tertentu
itu on-line atau off-line.

Objek data dan control dapat dihubungkan dengan objek data dan control lainnya.
Sebagai contoh, objek data paycheck memiliki satu hubungan atau lebih dengan objek
timecard, employee, bank dan lain-lain. Selama analisis domain informasi, hubungan-
hubungan itu harus ditetapkan.

Aliran informasi mewakili cara dimana data dan kontrol berubah pada saat masing-
masing bergerak melalui sebuah system. Spereti diperlihatkan pada Gambar 11.3,
objek input ditransformasikan ke informasi intermediate ( data dan atau control), dan
lebih jauh lagi ditransformasikan ke output. Sepanjang jalur transformasi tersebut,
informasi tambahan dapat dimunculkan dari penyimpanan data yang ada (seperti, file
disket atau memory buffer). Transformasi yang diaplikasikan merupakan fungsi atau
subfungsi yang harus dilakukan oleh sebuah program. Data dan control yang bergerak
diantara dua (fungsi) transformasi menentukan interface dari masing-masing fungsi.

Struktur informasi mewakili organisasi internal dari berbagai jenis data dan control.
Apakah jenis data akan diorganisasi sebagai sebuah table n-dimensi atau sebagai
sebuah struktur pohon hirarki? Dalam konteks struktur, informasi apa yang
dihubungkan dengan informasi lain? Apakah semua informasi di isikan ke dalam
sebuah struktur tunggal atau akan digunakan struktur yang berbeda? Bagaimana
informasi dalam suatu struktur informasi berhubungan dengan informasi pada struktur
yang lain? Pertanyaan-pertanyaan tersebut dijawab dengan suatu penilaian struktur
informasi. Harus dicatat juga bahwa struktur data, konsep yang berhubungan yang
akan di diskusikan pada buku ini, mengacu pada perancangan dan implementasi
informasi.

2. Pemodelan
Kita menciptakan model untuk memperoleh pemahaman yang lebih baik
mengenai entitas actual yang akan dibangun. Bila entitas tersebut berupa sebuah
bentuk fisik (bangunan, pesawat, mesin), kita dapat membangun model yang identik
dalam bentuk dan potongan, tetapi dalam skala yang lebih kecil. Tetapi bila entitas
yang akan dibangun adalah perangkat lunak, maka model harus memakai bentuk yang
berbeda. Model harus dapat memodelkan informasi yang di transformasikan oleh
perangkat lunak, fungsi (dan subfungsi) yang memungkinkan transformasi terjadi, dan
tingkah laku system pada saat transformasi terjadi.

Selama analisis persyaratan perangkat lunak, kita menciptakan model system yang
akan dibuat. Model tersebut berfokus pada apa yang harus dilakukan oleh system,
bukan pada bagaimana system melakukannya. Dalam beberapa kasus, model yang
kita buat menggunakan notasi grafis yang menggambarkan informasi, pemrosesan,
tingkah laku system, dan karakteristik lain sebagai symbol yang berbeda dan dapat
dikenali. Bagian lain dari model dapat benar – benar tekstual. Informasi deskriptif
dapat diberikan dengan menggunakan bahasa natural atau bahasa khusus untuk
menggambarkan persyaratannya.

Prinsip analisis operasional kedua dan ketiga mengharuskan kita membangun model
fungsi dan tingkah laku :

1. Model fungsional.
Perangkat lunak mentransformasi informasi, dan untuk melakukannya,
perangkat lunak harus melakukan paling tidak tiga fungsi genetic: input,
pemrosesan, dan output. Pada saat model fungsional dari suatu aplikasi
dibuat, perekayasa perangkat lunak memfokuskan dri pada fungsi – fungsi
masalah khusus. Model fungsi dimulai dengan sebuah model tingkat
konteks tunggal (yakni nama perangkat lunak yang akan dibuat). Dengan
serangkaian iterasi , maka lebih banyak lagi detail fungsional diberikan,
smapai seluruh rancangan dari semua fungsionalitas system terwakili.
 2. Model tingkah laku.
Sebagian besar perangkat lunak merespon kejadian-kejadian dari dunia
luar. Karakteristik stimulus-respon ini membentuk dasar dari model tingkah
laku. Program computer selalu ada dalam pernyataan suatu mode tingkah
laku yang dapat di obeservasi secara eksternal (misalnya, penungguan,
penghitungan, pencetakan, polling) yang diubah hanya pada saat beberapa
event berlangsung. Contohnya, perangkat lunak akan tetap berada dalam
wait state sampai (1) jam internal menunjukkan bahwa beberapa interval
waktu telah berlalu, (2) satu event eksternal (misalnya, pergerakan mouse)
menyebabkan suatu interupsi, atau (3) sebuah system eksternal member
sinyal kepada perangkat lunak agar bergerak dengan beberapa cara. Model
tingkah laku menciptakan representasi pernyataan-pernyataan perangkat
lunak dan event-event yang menyebabkan perangkat lunak mengubah
pernyataan.

Model yang diciptakan selama analisis persyaratan melayani sejumlah peran penting :

 Model membantu analisis dalam memahami informasi, fungsi, dan

tingkah laku suatu system, sehingga membuat tugas analisis persyaratan
menjadi lebih mudah dan lebih sistematis.

 Model menjadi titik focus bagi kajian sehingga merupakan kunci bagi
penetuan kelengkapan, konsistensi, dan akurasi dari spesifikasi.

 Model menjadi dasar bagi pengerjaan desain, member perancang suatu

representasi esensial dari perrangkat lunak yang dapat diterjemahkan ke
dalam suatu konteks implementasi.

3. Pembagian
Masalah sering menjadi terlalu luas atau terlalu rumit untuk dipahami sebagai salah
satu kesatuan. Karena itulah kita cenderung membagi masalah seperti itu ke dalam
bagian-bagian sehingga dapat dipahami dengan mudah dan kemudian membangun
interface antara bagian-bagian tersebut, sehingga keseluruhan fungsi dapat dilakukan.
Prinsip analisis operasional keempat menyatakan bahwa domain informasi,
fungsional, dan tingkah laku perangkat lunak tidak dapat dibagi – bagi. Secara
konseptual, kita membangun sebuah representasi hirarki dari informasi atau fungsi
dan kemudian membagi elemen bagian paling atas (1). mengekpos detail pertambahan
 dengan bergerak secara vertical dalam hirarki (2). Mendekomposisi masalah dengan
bergerak secara horizontal dalam hirarki.

Persyaratan untuk perangkat lunak Safe Home dapat dianalisis dengan pembagian
domain informasi, fungsional, dan tingkah laku produk. Untuk mengilustrasikannya,
domain fungsional dari masalah tersebut akan di bagi-bagi.

Pendekatan pembagian yang telah di aplikasikan pada fungsi – fungsi Safe-home juga
dapat di aplikasikan padadomain informasi dan kelakuan system akan memberikan
wawasan tambahan ke dalam persyaratan system. Pada saat masalah di bagi – bagi,
interface di antara system – system ditarik. Data dan control yang bergerak melewati
suatu interface harus dibatasi untuk input yang diperlukan untuk melakukan fungsi
yang dinyatakan dan outputyang diperlukan oleh elemen fungsi atau system yang lain.

4. Pandangan Esensial dan Implementasi

Pandangan esensial persyaratan perangkat lunak menyajikan fungsi yang akan
dikerjakan dan informasi yang akan diproses tanpa melihat detail implementasinya.
Sebagai contoh, pandangan esensial dari fungsi Safe Home read sensor status tidak
tergantung pada bentuk fisik dari data atau tipe sensor yang digunakan. Pada
dasarnya, dapat diperdebatkan bahwa read status akan menjadi nama yang lebih
sesuai bagi fungsi tsb, karena fungsi itu tidak mengabaikan detail mekanisme input
keseluruhan. Dengan cara yang sama, sebuah model data esensial dari item data
phone number (diimplikasikan oleh fungsi dial phone number) dpt di representasikan
pada tahap ini tanpa menghiraukan struktur data yang utama (bila ada) yang
digunakan untuk mengimplementasi item data.

Pandangan implementasi dari persyaratan menyajikan manifestasi dunia nyata dari

pemrosesan fungsi – fungsi dan struktur informasi. Perangkat input Safe Home
merupakan sebuah sensor perimeter. Sensor tsb mendeteksi masukan ilegal dengan
“mengendus” adanya break dalam sebuah rangkaian listrik. Analisis harus mengenali
batasan yang dikenakan oleh elemen system yang diberlakukan oleh elemen (sensor)
system sebelumnya dan mempertimbangkan pandangan implementasi fungsi dan
informasi bila pandangan semacam itu sesuai.

2.4 PROTOTYPING PERANGKAT LUNAK

Analisis harus dilakukan tanpa mengabaikan pardigma rekayasa perangkat
lunak yang di aplikasikan; tetapi bentuk yang di ambil oleh analisis akan bermacam –
macam. Dalam situasi yang lain, dilakukan pengumpulan persyaratan (melalui FAST,
QFD, atau teknik “cuci otak” yang lain [JOR89], pengaplikasian prinsip analisis, dan
penyusunan model perangkat lunak yang akan di bangun yang disebut prototype,
untuk penilaian pelanggan dan pengembang.
1. Pemilihan Pendekatan Prototyping
Paradigma protyping dapat terbatas atau tidak terbatas. Pendekatan terbatas
sering disebut throwaway prototyping. Dengan menggunakan pendekatan tsb,
prototype melulu sebagai sebuah demonstrasi kasar dari persyaratan.
Pendekatan tidak terbatas, yang disebut juga evolutionary prototyping,
menggunakan prototype sebagai bagian pertama dari aktivitas analisis yang
akan diteruskan kedalam desain dan kontruksi. Prototipe perangkat lunak
merupakan evolusi pertama dari system yang diselesaikan.
Secara umum, sembarang aplikasi yang menciptakan tampilan visual yang
dinamis, berinteraksi erat dengan pemakai manusia, atau membutuhkan
algoritma atau pemrosesan kombinatorial yang harus dikembangkan dalam
sebuah gaya evolusioner, adalah calon untuk prototyping.
2. Metode dan peranti prototyping
Supaya prototyping perangkat lunak efektif, maka harus dikembangkan suatu
prototype dengan cepat sehingga pelanggan dapat menilai hasil dan perubahan
yang di rekomendasi. Untuk melakukan prototyping secara cepat, ada tiga
kelas metode dan peranti generic: teknik generasi keempat, komponen
perangkat lunak reusable, spesifikasi formal, dan lingkungan prototyping.

Teknik Generasi Keempat (4GT). Teknik generasi keempat meliputi suatu

array yang luas dari query database dan bahasa pelaporan, program dan
generator aplikasi, serta bahasa nonprocedural. Karena 4GT memungkinkan
perekayasa perangkat lunak memunculkan kode yang dapat dieksekusi dengan
cepat, maka 4GT ideal untuk prototyping yang cepat. Komponen Perangkat
Lunak Reusable. Pendektan lain ke rapid prototyping adalah dengan
memasang, bukan membangun, prototype dengan menggunakan serangkaian
komponen perangkat lunak yangada.Pada setiap kasus, komponen perangkat
lunak harus dirancang dengan cara terntentu sehingga memungkinkannya
untuk dipakai kembali tanpa harus mempunyai pengetahuan yang mendetail
mengenai kerja internalnya. Perlu di catat bahwa sebuah produk perangkat
 lunak yabg ada dapat digunakan sebagai sebuah prototype bagi produk
kompetitif yang “baru dan telah dikembangkan”. Dengan cara tertentu, hal tsb
merupakan suatu bentuk dari reusabilitas untuk prototyping perangkat lunak.

Lingkungan Prototyping dan Spesifikasi Formal. Selama dua decade terakhir,

sejumlah bahasa spesifikasi formal dan peranti telah dikembangkan sebagai
pengganti bagi teknik spesifikasi bahasa natural. Sekarang pengembang
bahasa formal itu berada dalam proses pengembangan lingkungan interaktif
yang (1) memungkinkan seorang analisis untuk secara interaktif menciptakan
spesifikasi system atau perangkat lunak yang berdasarkan pada bahasa, (2)
memanggil peranti otomatis yang menerjemahkan spesifikasi berdasarkan
bahasa kedalam kode yang dapat di eksekusi, dan (3) memungkinkan
pelanggan untuk menggunakan kode prototype yang dapat di eksekusi untuk
menyaring persyaratan-persyaratan formal.

Dalam pembuatan software, dikenal beberapa metode untuk membuat software yang
dibutuhkan untuk memenuhi kebutuhan user yang memerlukan software tersebut. Pada
kesempatan kali ini, saya akan membahas salah satu metode pembuatan software yang
dimana baru-baru ini saya dan kelompok saya bahas dikampus untuk menyelesaikan tugas
mata kuliah rekayasa perangkat lunak yaitu model prototype(Prototyping Model)

Sebelum memasuki lebih mendalam mengenai pembuatan software menggunakan metode

prototype, kita harus terlebih dahulu mengetahui apa yang dimaksud dengan prototype itu
sendiri. Prototype adalah model atau simulasi dari semua aspek produk sesungguhnya yang
akan dikembangkan yang dimana model tersebut harus representative dari produk akhirnya.
Setelah mengetahui arti prototype mungkin masih menganjal dibenak kita bagaimana sih
software itu terbentuk menggunakan metode prototype? Apakah model prototype lebih bagus
digunakan daripada model lain? Apakah resiko-resiko dari penggunaan model tersebut? Dan
mungkin masih banyak pertanyaan lain yang akan muncul. Oleh sebab itu, pada postingan kali
ini saya sendiri akan menjelaskan lebih lanjut mengenai pembuatan software dengan
menggunakan metode prototype tersebut.

 Model Prototype

Menurut saya sendiri prototyping model adalah suatu proses pembuatan software
yang yang bersifat berulang dan dengan perencanaan yang cepat yang dimana
terdapat umpan balik yang memungkinkan terjadinya perulangan dan perbaikan
software sampai dengan software tersebut memenuhi kebutuhan dari si pengguna.
Sedangkan dari beberapa referensi yang saya temukan, prototyping model adalah
salah satu model sederhana pembuatan software yang dimana mengijinkan
pengguna memiliki suatu gambaran awal/dasar tentang program serta melakukan
oengujian awal yang didasarkan pada konsep model kerja(working model).

 Tujuan Prototype

Prototyping model sendiri mempunyai tujuan yaitu mengembangkan model awal

software menjadi sebuah sistem yang final.

 Proses-prosesnya

Proses-proses dalam model prototyping yaitu:

1) Komunikasi terlebih dahulu yang dilakukan antara pelanggan dengan
tim pemgembang perangkat lunak mengenai spesifikasi kebutuhan yang
diinginkan.
2) Akan dilakukan perencanaan dan pemodelan secara cepat berupa
rancangan cepat(quick design) dan kemudian akan memulai konstruksi
pembuatan prototype.
3) Prototipe kemudian akan diserahkan kepada para stakeholder untuk
dilakukan evaluasi lebih lanjut sebelum diserahkan kepada para pembuat
software.
4) Pembuatan software sesuai dengan prototype yang telah dievaluasi yang
kemudian akan diserahkan kepada pelanggan.
5) Jika belum memenuhi kebutuhan dari pelanggan maka akan kembali ke
proses awal sampai dengan kebutuhan dari pelanggan telah terpenuhi.

Sedangkan proses-proses dalam model prototyping secara umum adalah sebagai berikut:
1. Pengumpulan kebutuhan
developer dan klien akan bertemu terlebih dahulu dan kemudian menentukan tujuan
umum, kebutuhan yang diketahui dan gambaran bagian-bagian yang akan dibutuhkan
berikutnya
2. Perancangan
perancangan dilakukan dengan cepat dan rancangan tersebut mewakili semua aspek
software yang diketahui, dan rancangan ini menjadi dasar pembuatan prototype
3. Evaluasi Prototype
klien akan mengevaluasi prototype yang dibuat dan digunakan untuk memperjelas
kebutuhan software.

 Tahapan-tahapannya

Selain itu, untuk memodelkan sebuah perangkat lunak dibutuhkan beberapa tahapan
di dalam proses pengembangannya. Tahapan inilah yang akan menentukan
keberhasilan dari sebuah softwareitu .Pengembang perangkat lunak harus
memperhatikan tahapan dalam metode prototyping agar software finalnya dapat
diterima oleh penggunanya. Dan tahapan- tahapan dalam prototyping tersebut adalah
sebagai berikut :
1. Pengumpulan kebutuhan
Pelanggan dan pengembang bersama-sama mendefinisikan format dan
kebutuhan kesseluruhan perangkat lunak, mengidentifikasikan semua
kebutuhan, dan garis besar sistem yang akan dibuat.
2. Membangun prototyping
Membangun prototyping dengan membuat perancangan sementara yang
berpusat pada penyajian kepada pelanggan (misalnya dengan membuat
input dan contoh outputnya).
3. Evaluasi protoptyping
Evaluasi ini dilakukan oleh pelanggan apakah prototyping yang sudah
dibangun sudah sesuai dengan keinginan pelanggan. Jika sudah sesuai
maka langkah keempat akan diambil. Jika tidak, maka prototyping
diperbaiki dengan mengulang langkah 1, 2 , dan 3.
4. Mengkodekan system
Dalam tahap ini prototyping yang sudah disepakati diterjemahkan ke
dalam bahasa pemrograman yang sesuai.
5. Menguji system
 Setelah sistem sudah menjadi suatu perangkat lunak yang siap pakai,
harus dites dahulu sebelum digunakan. Pengujian ini dilakukan dengan
White Box, Black Box, Basis Path, pengujian arsitektur dan lain-lain.
6. Evaluasi Sistem
Pelanggan mengevaluasi apakah sistem yang sudah jadi sudah sesuai
dengan yang diharapkan . Jika sudah, maka langkah ketujuh dilakukan,
jika belum maka mengulangi langkah 4 dan 5.
7. Menggunakan system
Perangkat lunak yang telah diuji dan diterima pelanggan siap untuk
digunakan.

 Keunggulan dan kelemahan metode

prototype Keunggulan prototyping :

1. Komunikasi akan terjalin baik antara pengembang dan pelanggan.
2. Pengembang dapat bekerja lebih baik dalam menentukan
kebutuhan setiap pelanggannya.
3. Pelanggan berperan aktif dalam proses pengembangan sistem.
4. Lebih menghemat waktu dalam pengembangan sistem.
5. Penerapan menjadi lebih mudah karena pemakai mengetahui apa
yang diharapkannya

Kelemahan prototyping :
1. Pelanggan kadang tidak melihat atau menyadari bahwa
perangkat lunak yang ada belum mencantumkan kualitas perangkat lunak
secara keseluruhan dan juga belum memikirkan kemampuan
pemeliharaan untuk jangka waktu lama.
2. Pengembang biasanya ingin cepat menyelesaikan proyek
sehingga menggunakan algoritma dan bahasa pemrograman yang
sederhana untuk membuat prototyping lebih cepat selesai tanpa
memikirkan lebih lanjut bahwa program tersebut hanya merupakan
sebuah kerangka kerja(blueprint) dari sistem .
3. Hubungan pelanggan dengan komputer yang disediakan
mungkin tidak mencerminkan teknik perancangan yang baik dan benar.

Dalam setiap metode mempunyai kelebihan maupun kekurangan, namun kekurangan

tersebut dapat diminimalisir yaitu dengan mengetahui kunci dari model prototype
tersebut. Kunci agar model prototype ini berhasil dengan baik adalah dengan
mendefinisikan aturan- aturan main pada saat awal, yaitu pelanggan dan pengembang
harus setuju bahwa prototype dibangun untuk mendefinisikan kebutuhan.
 BAB III

PENUTUP

3.1 Kesimpulan
Perkembangan dunia industri teknologi di dunia semakin pesat, hal ini menjadikan
persaingan setiap perusahaan semakin kuat pula. Jika di hubungkan dengan pemodelan analisis
perangkat lunak terletak pada jenis pemodelannya, karena pada dasarnya pemodelan analisis
bermacam-macam. Hal inilah yang di manfaatkan oleh perusahaan perangkat lunak atau
pembuatan software.

3.2 Saran
Sekiranya makalah ini dapat menjadikan acuan teman-teman untuk bisa bersaing dalam
membuat software agar mendapatkan jenis analisis yang tepat dan sesuai permintaan konsumen.
Walau kami sadari bahwa makalah kami tidak sempurna, maka dari itu kami sangat
mengharapkan masukan atau saran yang dapat membangun, agar dapat menjadi acuan dan
motivasi makalah kami berikutnya.
 DAFTAR PUSTAKA
Oracle. 2012. Oracle Bussiness Intelligence Publisher.Oracle. Amerika Serikat.
(http://www.oracle.com/technetwork/m iddleware/bi-publisher/overview /index.htm
ldiakses pada
1 April 2012).
Parr, T. 2004. Enforcing Strict M odel-View Separation in Template Engines.Prosiding
Konferensi:
World Wide Web. Association for Computing Machinery. Amerika Serikat.
Putra, Hanson Prihantoro. 2014. Laporan Penelitian: Prototipe M anajemen Dokumentasi
Rekayasa
Perangkat Lunak.Universitas Islam Indonesia. Yogyakarta. Indonesia.
Roth, M.L. 2009. Software Document Generator.US Patent No. US 758184 B1. Amerika
Serikat.
Sarkar, S dan Cleaveland, C. (2001). Code Generation using XML Based Document
Transform ation.
The Server Side - Your J2EE Community.
Rochimah, Siti. 1999. Pengembangan Dokumentasi Standard untuk Tahapan Rekayasa
Perangkat
Lunak.Lembaga Penelitian, Institut Teknologi Bandung. Bandung. Indonesia.
Teknik Informatika UII. 2011. Buku Panduan Akademik: Jurusan Teknik Informatika,
Fakultas Teknologi Industri, 2011/2012. Yogyakarta. Universitas Islam Indonesia.
Yogyakarta. Indonesia.