MAKALAH REKAYASA PERANGKAT LUNAK

NORDIN FAJAR AHMAD

22010073

DOSEN PENGAMPU : MASHURI ALBANTARI, S.Kom, M.Kom

INSTITUT TEKNOLOGI DAN SAINS MERANTI

TAHUN AJARAN 2022/2023

 KATA PENGANTAR

Puji dan syukur kepada Tuhan Yang Maha Esa yang telah memberikan
rahmat serta hidayah-Nya, sehingga penulis dapat menyelesaikan makalah ini.

Penulis menyusun makalah guna memenuhi tugas yang diberikan oleh

bapak Mashuri Albantari selaku dosen pengampu mata kuliah Pengantar Rekayasa
Dan Desain dan selain itu semoga makalah ini dapat bermanfaat bagi orang lain.

Dengan penuh kerendahan hati penulis menyadari bahwa apa yang penulis
tuliskan dalam makalah ini masih jauh dari kesempurnaan dan tentunya tidak
luput dari kesalahan.

Selat Panjang, 06 Mei 2023

Penulis

ii
 DAFTAR ISI

KATA PENGANTAR......................................................................................................ii
DAFTAR ISI...................................................................................................................iii
BAB I.................................................................................................................................1
PENDAHULUAN.............................................................................................................1
1.1.Latar Belakang Masalah........................................................................................1
1.2.Rumusan Masalah..................................................................................................2
1.3. Tujuan....................................................................................................................2
BAB II...............................................................................................................................3
TINJAUAN TEORI.........................................................................................................3
2.1. Konsep Rekayasa Perangkat Lunak....................................................................3
2.2. Software Process....................................................................................................5
2.3. Requirement Modelling........................................................................................7
2.4. Business Rules........................................................................................................9
2.5. Software Design...................................................................................................11
2.6. Software Documentation.....................................................................................14
2.7. Configuration Management................................................................................15
2.8. Software Quality..................................................................................................16
2.9. Software Testing Strategy ..................................................................................17
2.10. Software Evolution............................................................................................19
2.11. UML...................................................................................................................20
BAB III............................................................................................................................25
PENUTUP ......................................................................................................................25
3.1. Kesimpulan..........................................................................................................25
3.2. Saran....................................................................................................................25
DAFTAR PUSTAKA.....................................................................................................26

iii
iv
 BAB I

PENDAHULUAN

1.1. Latar Belakang Masalah

Pada masa sekarang, rasanya hampir semua bidang kehidupan tersentuh

penggunaan perangkat lunak atau software. Beberapa perangkat lunak mungkin
sudah terbiasa kita gunakan atau kita lihat seperti perangkat lunak untuk
memainkan atau membuat musik, perangkat lunak untuk membantu kasir dalam
penjualan barang, perangkat lunak untuk mengetik dokumen, dan lain-lain.
Perangkat lunak ini merupakan hasil dari serangkaian proses atau kegiatan yang
dikenal sebagai Rekayasa Perangkat Lunak. Istilah Rekayasa Perangkat Lunak
(RPL) secara umum disepakati sebagai terjemahan dari istilah Software
Engineering . Istilah Software Engineering mulai dipopulerkan tahun 1968 pada
Software Engineering Conference yang diselenggarakan oleh NATO. Sebagian
orang mengartikan RPL hanya sebatas pada bagaimana membuat program
komputer. Padahal ada perbedaan yang mendasar antara perangkat lunak
( software ) dan program komputer. Perangkat lunak adalah seluruh perintah yang
digunakan untuk memproses informasi. Perangkat lunak dapat berupa program
atau prosedur. Program adalah kumpulan perintah yang dimengerti oleh
komputer sedangkan prosedur adalah perintah yang dibutuhkan oleh pengguna
dalam memproses informasi (O’Brien, 1999).

1.2. Rumusan Masalah

1
 Berdasarkan latar belakang di atas dapat penulis rumuskan permasalahan,
yaitu :

1. Apa yang dimaksud dengan RPL?

2. Apa saja konsep dari RPL?
3. Apa saja bagian – bagian dari RPL?

1.3. Tujuan

1. Untuk mengetahui yang dimaksud RPL

2. Untuk mengetahui konsep RPL
3. Untuk mengetahui bagian – bagian dari RPL

2
 BAB II

TINJAUAN TEORI

2.1. Konsep Rekayasa Perangkat Lunak

Rekayasa Perangkat Lunak (Software Engineering) adalah suatu disiplin ilmu

yang berkaitan dengan proses pembuatan, pengembangan, pemeliharaan, dan
dokumentasi perangkat lunak secara sistematis dan terstruktur. Tujuannya
adalah untuk menghasilkan perangkat lunak yang berkualitas, efisien, dan
dapat dipercaya.

Konsep dalam Rekayasa Perangkat Lunak meliputi:

A. Proses Pengembangan Perangkat Lunak

Terdiri dari beberapa tahapan mulai dari analisis kebutuhan, desain,

implementasi, pengujian, hingga pemeliharaan. Proses ini dilakukan secara
iteratif dan incremental untuk memastikan bahwa perangkat lunak yang
dihasilkan sesuai dengan kebutuhan pengguna dan dapat dikembangkan
dengan mudah di masa depan.

B. Manajemen Proyek Perangkat Lunak

Meliputi perencanaan, pengorganisasian, pengendalian, dan monitoring

proyek perangkat lunak. Tujuannya adalah untuk memastikan proyek berjalan
sesuai jadwal, anggaran, dan kualitas yang diharapkan.

C. Pengujian Perangkat Lunak

3
Proses pengujian dilakukan untuk memastikan bahwa perangkat lunak yang
dihasilkan berfungsi dengan baik dan sesuai dengan kebutuhan pengguna.
Pengujian dilakukan dalam beberapa tahap, mulai dari pengujian unit,
integrasi, sistem, hingga pengujian penerimaan.

D. Dokumentasi Perangkat Lunak

Dokumentasi perangkat lunak penting untuk memudahkan pengembangan dan

pemeliharaan perangkat lunak di masa depan. Dokumentasi meliputi
dokumentasi kebutuhan, desain, implementasi, dan pengujian.

E. Pengembangan Perangkat Lunak Berbasis Tim

Pengembangan perangkat lunak tidak bisa dilakukan oleh satu orang saja,
melainkan membutuhkan tim yang terdiri dari berbagai spesialisasi seperti
analis sistem, perancang, programmer, dan tester. Komunikasi dan kolaborasi
yang baik antar anggota tim sangat penting untuk memastikan keberhasilan
proyek.

F. Kualitas Perangkat Lunak

Kualitas perangkat lunak penting untuk memastikan keberhasilan penggunaan

perangkat lunak. Kualitas perangkat lunak dapat diukur dengan berbagai
metrik seperti reliabilitas, kinerja, dan keamanan.

G. Reusabilitas Perangkat Lunak

Reusabilitas perangkat lunak penting untuk mempercepat proses

pengembangan dan mengurangi biaya pengembangan. Reusabilitas dapat
dicapai dengan menggunakan metode dan alat pengembangan perangkat lunak
yang terstruktur dan sistematis.

4
2.2. Software Process

Proses perangkat lunak adalah serangkaian langkah-langkah, metode, dan praktik

yang digunakan dalam produksi dan evolusi perangkat lunak. Proses perangkat
lunak mencakup serangkaian artefak terkait, sumber daya manusia dan komputer,
struktur dan batasan organisasi. (Watts Humphrey dan P.H. Feiler)

Terdapat 4 aktifitas umum yang mendasar pada semua proses rekayasa perangkat
lunak, yaitu:

1. Software specification, yaitu pengguna dan perekayasa menentukan

perangkat lunak yang akan dibuat dan dibatasi pada proyek tersebut.

2. Software development, dimana perangkat lunak tersebut dirancang dan

diprogram.

3. Software validation, dimana perangkat lunak di cek apakah sudah

memenuhi apa yang dibutuhkan oleh pengguna

4. Software evolution, dimana perangkat lunak diubah, diperbaiki untuk

mengatasi perubahan pengguna dan mengikuti perkembangan jaman.

Dalam software process terdapat beberapa model, yaitu:

Waterfall, Model ini adalah model yang pertama kali muncul pada tahun 1970an
diperkenalkan oleh Winston W. Royce. Model ini memisahkan fase spesifikasi
dengan fase pengembangan.

Ada 5 proses penting dalam model Waterfall:

5
1. Requirement analysis and definition (analis kebutuhan)

2. System and software design (perancangan sistem dan software)

3. Implementation and unit testing (implementasi dan testing)

4. Integration and system testing (integrasi dan pengujian sistem)

5. Operation and maintenance (operasi dan perawatan)

RAD (Rapid Application Development), Rapid Application Development (RAD)

adalah sebuah strategi pengembangan sistem yang menekankan kecepatan dalam
pengembangan melalui keterlibatan pengguna dalam pembangunan secara cepat,
iteratif, dan incremental dari suatu serangkaian prototype dari suatu sistem yang
dapat berkembang menjadi suatu sistem akhir atau versi tertentu.

Prototyping Model, Pada model ini, user berperan aktif dalam pembuatan
software. model ini digunakan apabila developer kesulitan dalam pengumpulan
kebutuhan dan user juga tidak dapat menggambarkan software yang
diinginkannya, atau dimana user sering menambah dan mengubah apa yang
diinginkannya

Banyak proses perangkat lunak yang berbeda tetapi semuanya

melibatkan:

1. Spesifikasi - menentukan apa yang harus dilakukan sistem;

2. Desain dan implementasi - mendefinisikan organisasi system dan

mengimplementasikan sistem;

6
 3. Validasi - memeriksa apakah ia melakukan apa yang diinginkan
pelanggan;

4. Evolusi - mengubah sistem sebagai respons terhadap perubahan

kebutuhan pelanggan..

2.3. Requirement Modelling

Requirements model adalah penyajian teknis awal/pertama dari suatu sistem.

Rangkaian kalimat atau kata-kata yang dituliskan adalah cara yang baik untuk
berkomunikasi, tetapi tidak selalu merupakan cara terbaik untuk menyajikan
requirements untuk software komputer. Requirements Modeling menggunakan
kombinasi berbentuk teks dan diagram untuk menyajikan requirements dengan
cara yang relatif mudah dipahami, dan yang lebih penting, langsung digunakan
untuk me-review kebenaran, kelengkapan, dan konsistensi dari requirements.

untuk memvalidasi software requirements, kita perlu memeriksanya dari sejumlah

sudut pandang berbeda. Misalkan kita akan mempertimbangkan requirements
modeling dari tiga perspektif berbeda: scenario-based models (model berbasis
skenario), data (information) model (model data/informasi), dan class-based
model (model berbasis class). Catatan: beberapa jenis pemodelan yang lain
misalnya adalah behavioral and patterns-based model (model berbasis behavior
dan pola), flow-oriented model (model berorientasi aliran data). Masing-masing
menyajikan requirements dalam "dimensi" yang berbeda, dengan demikian
meningkatkan probabilitas untuk menemukan kesalahan, inkonsistensi akan
muncul, dan kelalaian.

Scenario-based modeling (pemodelan berbasis skenario) menyajikan sistem dari

sudut pandang pengguna. Data modeling (pemodelan data) menyajikan
data/informasi dan menggambarkan objek data yang akan dimanipulasi oleh
7
software dan hubungan di antara objek data tersebut. Class-based modeling
(pemodelan berbasis kelas) mendefinisikan objek-objek, atribut-atribut, dan
realtionships mereka. Setelah model awal dibuat, model-model tersebut
disempurnakan dan dianalisis untuk menilai kejelasan, kelengkapan, dan
konsistensi mereka. 

Hasil/produk kerja requirements modeling harus di-review untuk memastikan

kebenaran, kelengkapan, dan konsistensi. Hasil ini harus mencerminkan
kebutuhan semua pemangku kepentingan dan membangun fondasi dimana desain
bisa mulai dijalankan.

Beberapa jenis/kategori model dalam requirements engineering

a. Model berdasarkan scenario, contoh: use case diagram, user story, activity
diagram, use case scenario, dll. Pada pemodelan berdasarkan scenario bertujuan
untuk membantu mendefinisikan actor dari sistem dan apa yang harus dilakukan
oleh sistem tersebut.

b. Model berdasarkan class, contoh: class diagram, collaboration diagram, dll.

Model berdasarkan class menggambarkan beberapa hal berikut:
 Object dari sistem yang akan dimanipulasi.
 Operasi (metode atau service) yang akan diterapkan terhadap object untuk
mendapatkan efek dari manipulasi yang dilakukan.
 Hubungan antar object
 Kolaborasi yang muncul antara kelas yang didefinisikan.
c. Model berdasarkan behavior, contoh state diagram, sequence diagram, dll.
Model behavior mengindikasikan bagaimana software akan memberikan respon
terhadap event atau stimulus external. Untuk menciptakan model ini, proses
analisis harus dilakukan melalui tahapan berikut:
8
 Evaluasi semua use case untuk memahami secara keseluruhan urutan
interaksi di dalam sistem.
 Identifikasikan sistem yang menggerakan urutan interaksi dan memahami
bagaimana event-event tersebut dikaitkan dengan object specific.
 Membuat sequence untuk setiap use case
 Membangun state diagram untuk sistem
 Melakukan review terhadap model behavioral untuk verifikasi akurasi dan
konsistensi
d. Model berdasarkan aliran, contoh: data flow diagram, data models.

2.4. Business Rules

Organisasi bisnis bekerja berdasar pada seperangkat aturan-aturan, hukum,

kebijakan dan standar industri. Misalnya industri perbankan, penerbangan dan
pabrik penghasil perangkat medis harus selaras dengan sejumlah regulasi
pemerintah. Prinsip-prinsip pengendalian inilah yang sering kita kenal sebagai
aturan bisnis atau business rules.
Aturan bisnis merupakan salah satu sumber utama kebutuhan fungsional
perangkat lunak. Hal ini dikarenakan aturan bisnis bisa mendikte/memaksa sistem
untuk memiliki kemampuan/fungsi/fitur tertentu yang juga digunakan untuk
mengkonfirmasikan aturan-aturan itu sendiri.

Menurut Business Rules Group (1993), aturan bisnis adalah pernyataan yang
mendefinisikan atau membatasi beberapa aspek bisnis. Adanya aturan-aturan
bisnis ini dimaksudkan untuk menegaskan struktur bisnis atau untuk
mengendalikan atau mempengaruhi perilaku bisnis.
Aturan bisnis biasanya dituliskan dalam dokumentasi sederhana terkait sistem
yang dibangun dan menghubungkannya dengan spesifikasi kebutuhan fungsional.
9
Klasifikasi Aturan Bisnis

Ada lima tipe aturan bisnis yaitu Facts, Constraints, Action Enablers,
Computations dan Inferences.

1. Facts (fakta) adalah pernyataan yang benar tentang bisnis.

Contoh:
Setiap mahasiswa memiliki kode unik berupa NIM
Setiap pesananan makanan dikenakan pajak
2. Constraints artinya membatasi aksi-aksi yang boleh dilakukan oleh sistem
atau user. Kata-kata kunci dalam membuat pernyataan constraint biasanya
terdiri dari kata harus, harus tidak, tidak boleh dan hanya.
Contoh:
Hanya user yang sudah terdaftar saja yang bisa memesan paket wisata
Pemilik rekening yang berusia di bawah 17 tahun harus menyertakan surat
penjamin dan tanda pengenal orang tuanya
Ukuran file attachment hanya boleh maksimal 5 Mb.
3. Action Enablers adalah aturan yang memicu terjadinya beberapa aktivitas
di bawah kondisis khusus/tertentu. Pernyataan action enabler biasanya
ditulis dengan situasi “JIKA <kondisi benar atau kejadian tertentu terjadi>,
MAKA <sesuatu akan tejadi>”.
Contoh
Jika stok barang kurang dari lima maka diberi arsir warna merah
Jika password yang dimasukkan kurang dari delapan karakter, maka keluar
pesan “Password Anda kurang dari 8 Karakter. Silakan Coba lagi”.
Jika file attachment lebih dari 5 Mb, maka keluar pesan bahwa ukuran
attachment melebih batas yang dijinkan.

10
 4. Inferences sebenarnya mirip dengan action enablers yaitu harus
terpenuhinya kondisi tertentu. Hanya saja perbedaannya jika kondisi benar
atau terpenuhi, maka tidak menyebabkan sesuatu akan terjadi, melainkan
menciptakan satu fakta (fact) baru atau sepotong informasi baru.
Contoh:
Jika dalam 30 hari pesanan tidak dibayar, maka pesanan hangus.
Bahan kimia yang mengandung toksin lebih kecil dari 5 mg/kg
dimasukkan kategori berbahaya
5. Computations merupakan aturan-aturan bisnis yang menentukan
komputasi apa yang harus dikerjakan oleh sistem menggunakan formula
matematika atau algoritma tertentu.
Contoh:
Kekayaan Bersih = Total Aset – Total Hutang

2.5. Software Design

Desain perangkat lunak merupakan salah satu tahapan pengembangan perangkat

lunak yang menjadi jembatan dari analisis dan implementasi program. Detail
teknis dihasilkan dari desain perangkat lunak sehingga pengembang perangkat
lunak mudah mengimplementasikan atau membuat perangkat lunak.

Jenis desain perangkat lunak :

1. Desain data
Pengaruh struktur data pada struktur program dan kompleksitas prosedural
menyebabkan desain data berpengaruh penting terhadap kualitas perangkat lunak,
konsep penyembunyian informasi dan abstraksi data memberi dasar pendekatan
terhadap desain data.

11
2. Desain arsitektur
Sasaran utama desain arsitektur adalah untuk mengembangkan struktur program
modular dan merepresentasikan hubungan kontrol antar modul. Desain arsitektur
juga membentuk struktur program dan struktur data dengan menentukan interface
yang memungkinkan data mengalir melalui program.

3. Desain interface

12
Pengguna (User Interface Design) atau rekayasa antarmuka pengguna (User
Interface Engineering) adalah desain untuk komputer, peralatan, mesin, perangkat
komunikasi mobile, aplikasi perangkat lunak, dan situs web yang berfokus pada
pengalaman pengguna (User Experience) dan interaksi.

4. Desain prosedural
Dalam dunia yang ideal, spesifikasi prosedural diperlukan untuk menetapkan
detail algoritma yang akan dinyatakan dalam suatu bahasa ibu, seperti Bahasa
Indonesia. Desain prosedural harus menentukan detail desain prosedural tanpa ada
ambiguitas.

13
2.6. Software Documentation

Dokumentasi perangkat lunak menjabarkan program-program yang dirancang dan

dikode untuk mendukung fungsi tersebut. Dokumentasi ini terdiri dari:

1. Dokumentasi internal

2. Dokumentasi eksternal

Dokumentasi Perangkat Lunak Internal Adalah penggabungan dokumentasi

kedalam kode program, fasilitas seperti ini dianggap sebagai bahasa “self-
documenting”. Contoh dari dokumentasi ini adalah program COBOL yang dapat
terbaca seperti bahasa Inggris sederhana.Contoh listing COBOL:

P1. IF HOURS > 40 PERFORM P2

ELSE PERFORM P3

P2. COMPUTE RP = R * 40

COMPUTE OT = 1.5 * R * (H – 40)

COMPUTE GP = RP + OT

P3. COMPUTE RPGP = R * H

Dengan penerapan nama-nama yang bermakna dan standar, segmen tersebut

diatas dapat dikonversi kesegmen yang juga dapat dipahami oleh non-
programmer, yaitu seperti berikut ini (untuk segment P1):
14
COMPUTE-GROSSPAY.

IF HOURS-WORKED > 40

PERFORM GROSSPAY-WITH-OVERTIME

ELSE

PERFORM GROSSPAY-WITHOUT-OVERTIME.

Seorang programmer dapat juga meningkatkan dokumentasi internal dari program

tersebut dengan memasukan atau menyisipkan komentar dan penjelasan yang
dibatasi dengan tanda bintang kedalam program tersebut.

Dokumentasi Perangkat Lunak Eksternal berbasis (menggunakan)-Kertas Ada

sejumlah form yang dapat digunakan untuk mendokumentasikan program
perangkat lunak. Setiap perusahaan biasanya menetapkan standart Dokumentasi
eksternal berbasis-Kertasnya sendiri yang disesuaikan dengan item-item yang
dibutuhkan.

2.7. Configuration Management

Manajemen konfigurasi perangkat lunak (SCM), sering disebut juga manajemen

perubahan (change management), adalah serangkaian kegiatan yang dirancang
untuk mengelola perubahan dengan mengidentifikasi produk/hasil kerja yang
kemungkinan besar akan mengalami perubahan, membuat hubungan di antara
mereka, menentukan mekanisme untuk mengelola berbagai versi produk kerja
tersebut, mengendalikan perubahan yang terjadi, dan mengaudit dan melaporkan
perubahan yang dilakukan.
15
beberapa elemen dari Manajemen Konfigurasi Software (SCM)Software
Configuration Management):
 Component elements, sekumpulan dari tool yang dipasarkan dengan
manajemen sistem data (seperti database) yang memungkinkan akses ke
data tersebut dan melakukan pengaturan terhadap setiap item konfigurasi
software.
 Prosess elements, merupakan kumpulan dari prosedur dan tugas yang
mendefinisikan pendekatan yang efektif untuk melakukan manajemen
perubahan melibatkan semua yang terlibat dalam manajemen.
 Construction elements, kumpulan dari tool-tool yang mengautomasi
pembuatan software dengan memastikan validasi komponen yang layak
(misalnya, versi yang benar).
 Human elements, untuk mengimplementasikan SCM yang efektif,
tim software harus menggunakan sekumpulan feature tool dan proses.

2.8. Software Quality

Menurut steve McConnell’s, Code Complete membagi perangkat lunak kedalam

dua hal yaitu internal quality dan eksternal quality characteristics. Karakteristik
kualitas eksternal merupakan bagian dari suatu produk yang berhubungan dengan
para pemakainya, sedangkan kualitas internal tidak secara langsung berhubungan
dengan pemakai. Software quality didefinisikan sebagai kesesuaian yang
diharapkan pada semua software yang dibangun dalam fungsi software yang
diutamakan dan untuk kerja software, standar pembangunan yang terdokumentasi
dan karakteristik yang ditunjukan software [1]. Definisi ini menekankan pada 3
hal yaitu :

16
1. Kebutuhan software adalah pondasi ukuran kebutuhan software adalah pondasi
ukuran kualitas software, jika software tidak sesuai dengan kebutuhan yang
ditentukan maka kualitasnya pun kurang.

2. Jika menggunakan suatu standar untuk pembangunan software maka jika

software tidak memenuhi standar tersebut maka dianggap kurang berkualitas.

3. Seringkali ada kualitas yang secara langsung diutarakan (tersirat) seperti

kemudahan penggunaan dan pemeliharaan yang baik. Kualitas software
dipertanyakan jika tidak memenuhi kebutuhan ini.

Hal lain yang perlu diperhatikan dalam kualitas perangkat lunak adalah quality
assurarance (QA) yang merupakan acctivity of providing revidence. Selain itu
harus adanya software quality management (SQM). Tujuan dari SQM adalah
untuk mengembangkan suatu pemahaman kuantitatif dari kualitas proyek produk
perangkat lunak dan mencapai tujuan spesifik kualitasnya. Menurut IEEE,
kualitas perangkat lunak didefinisikan sebagai derajat dari sebuah sistem,
komponen atau proses yang memenuhi kebutuhan-kebutuhan yang
dispesifikasikan dan kebutuhan pengguna atau harapan pengguna.

2.9. Software Testing Strategy

software testing adalah sebuah metode yang dijalankan perusahaan untuk

memeriksa apakah aplikasi sudah sesuai dengan persyaratan yang diharapkan atau
belum. Tak hanya itu, software testing juga dilakukan untuk memastikan bahwa
produk bebas dari cacat.  Metode tersebut melibatkan proses pemeriksaan
komponen dalam sistem software menggunakan alat manual atau otomatis. 

17
 jenis-jenis software testing yang

1. Manual testing

Sesuai namanya, manual testing adalah proses pengujian software yang dilakukan

dengan tangan untuk mempelajari apakah fitur dalam aplikasi berfungsi atau
tidak.

2. Automation testing

Automation testing sendiri mengacu pada metode pengujian menggunakan alat

otomasi khusus guna menemukan cacat yang tak terlihat. Dalam proses kerjanya,
penguji perlu menjalankan skrip pengujian dan menemukan kesalahan sistem
menggunakan alat otomatisasi.Beberapa alat pengujian otomasi yang terkenal
untuk pengujian fungsional adalah QTP/UFT dan Selenium.

3. Performance testing

performance testing merupakan proses yang digunakan untuk menguji kecepatan,

waktu respons, stabilitas, keandalan, skalabilitas, dan penggunaan sumber
daya software di bawah beban kerja tertentu. Tahap pengujian ini juga biasa
dilakukan sebelum produk diluncurkan secara resmi ke publik.

4. Regression testing

Jenis test ini mengacu pada proses pemeriksaan fitur baru

dalam software. Developer perlu memeriksa apakah fitur-fitur tersebut merusak
atau menurunkan fungsionalitas software. Pengujian ini juga dapat digunakan
untuk memverifikasi kinerja menu, fungsi, dan perintah di UI, ketika tidak ada
waktu untuk uji regresi desain secara menyeluruh.
18
5. Statistic testing

Untuk menguji program atau aplikasi yang belum dijalankan, jenis software

testing yang bisa dijalankan adalah statistic testing.

6. Dynamic testing

Proses pengujian ini dilakukan saat program sedang berjalan atau kode program
sudah dieksekusi oleh para developer. Dengan memasukkan input ke dalamnya,
penguji bisa melihat dan membandingkan output dari softyware yang diinginkan.

2.10. Software Evolution

Evolusi perangkat lunak adalah seluruh aktivitas dan proses baik teknis maupun
manajerial yang bertujuan untuk menghasilkan versi perangkat lunak yang baru
dari versi operasional sebelumnya sehingga perangkat lunak tersebut tetap mampu
memenuhi kebutuhan bisnis dengan biaya yang efektif.

Proses perangkat lunak evolusi bervariasi tergantung pada jenis perangkat lunak
yang dipelihara, proses pengembangan yang digunakan dalam sebuah organisasi
dan keterampilan orang yang terlibat. Selama proses evolusi, persyaratan
dianalisis secara rinci dan implikasi dari perubahan muncul yang tidak jelas dalam
proses analisis perubahan sebelumnya. Ini berarti bahwa perubahan yang
diusulkan dapat dimodifikasi dan diskusi pelanggan lebih lanjut mungkin
diperlukan sebelum mereka diimplementasikan. permintaan perubahan kadang-
kadang berhubungan dengan masalah sistem yang harus ditangani segera.
Perubahan mendesak dapat timbul karena tiga alasan:

19
  Jika kesalahan sistem yang serius terjadi yang harus diperbaiki untuk
memungkinkan operasi normal untuk melanjutkan.

 Jika perubahan lingkungan sistem operasi memiliki efek tak terduga yang
mengganggu operasi normal.

 Jika ada perubahan yang tak terduga untuk bisnis menjalankan sistem,
seperti munculnya pesaing baru atau pengenalan undang-undang baru
yang mempengaruhi sistem.

2.11. UML

UML (Unified Modelling Language) adalah suatu metode dalam pemodelan

secara visual yang digunakan sebagai sarana perancangan sistem berorientasi
objek. Awal mulanya, UML diciptakan oleh Object Management Group dengan
versi awal 1.0 pada bulan Januari 1997.

UML juga dapat didefinisikan sebagai suatu bahasa standar visualisasi,

perancangan, dan pendokumentasian sistem, atau dikenal juga sebagai bahasa
standar penulisan blueprint sebuah software.

Adapun tujuan dan fungsi perlu adanya UML yaitu sebagai berikut:

1. Dapat memberikan bahasa pemodelan visual atau gambar kepada para

pengguna dari berbagai macam pemrograman maupun proses umum
rekayasa.
20
 2. Menyatukan informasi-informasi terbaik yang ada dalam pemodelan.

3. Memberikan suatu gambaran model atau sebagai bahasa pemodelan visual

yang ekspresif dalam pengembangan sistem.

4. Tidak hanya menggambarkan model sistem software saja, namun dapat

memodelkan sistem berorientasi objek.

5. Mempermudah pengguna untuk membaca suatu sistem.

6. Berguna sebagai blueprint, jelas ini nantinya menjelaskan informasi yang

lebih detail dalam perancangan berupa coding suatu program.

Contoh Diagram UML yang Sering Digunakan

1. Use Case Diagram

Gambar Use Case diagram ATM

Use Case Diagram adalah satu jenis dari diagram UML (Unified Modelling
Language) yang menggambarkan hubungan interaksi antara sistem dan aktor. Use
Case dapat mendeskripsikan tipe interaksi antara si pengguna sistem dengan
sistemnya. Use Case merupakan sesuatu yang mudah dipelajari. Langkah awal
untuk melakukan pemodelan perlu adanya suatu diagram yang mampu
21
menjabarkan aksi aktor dengan aksi dalam sistem itu sendiri, seperti yang terdapat
pada Use Case.

2. Activity Diagram

Gambar Activity Diagram

Activity diagram atau dalam bahasa Indonesia berarti diagram aktivitas,

merupakan sebuah diagram yang dapat memodelkan berbagai proses yang tejadi
pada sistem. Seperti layaknya runtutan proses berjalannya suatu sistem dan
digambarkan secara vertikal. Activity diagram adalah salah satu contoh diagram
dari UML dalam pengembangan dari Use Case.

3. Sequence Diagram

22
 Gambar Sequence Diagram

Sequence diagram merupakan diagram yang menjelaskan interaksi objek

berdasarkan urutan waktu. Sequence dapat menggambarkan urutan atau tahapan
yang harus dilakukan untuk dapat menghasilkan sesuatu, seperti yang tertera pada
Use Case diagram.

 4. Class Diagram

Gambar Class Diagram

23
Class diagram atau diagram kelas merupakan suatu diagram yang digunakan
untuk menampilkan kelas-kelas berupa pake-paket untuk memenuhi salah satu
kebutuhan paket yang akan digunakan nantinya.

5. Statemachine Diagram

Gambar Statemachine Diagram

Statemachine yaitu salah satu jenis diagram pada UML yang berfungsi untuk
menggambarkan transisi serta perubahan pada suatu objek pada sistem.

6. Component Diagram

Component diagram yang berfungsi untuk menggambarkan software pada

suatu sistem. Component diagram merupakan penerapan pada piranti lunak
atau software dari satu class maupun lebih, dan biasanya
berupa file data, source code,.exe, table, dokumen, 

24
 BAB III

PENUTUP

3.1 Kesimpulan

Perangkat lunak adalah seluruh perintah yang digunakan untuk memproses

informasi. Perangkat lunak dapat berupa program atau prosedur. Program adalah
kumpulan perintah yang dimengerti oleh komputer sedangkan prosedur adalah
perintah yang dibutuhkan oleh pengguna dalam memproses informasi

3.2 Saran

Dalam pembuatan makalah ini masih banyak kekurangan dan kesalahan

untuk itu kami membutuhkan kritik dan saran dari teman teman sekalian, sehingga
untuk pembuatan makalah selanjutnya kami sudah mengetahui kesalahan dan
kekurangan kami dan dapan menyusun makalah berikutnya lebih baik dari saran
saran yang teman berikan

25
 DAFTAR PUSTAKA

Buku Rekayasa Perangkat Lunak oleh Aunur R. Mulyanto

file:///C:/Users/user/Downloads/Software_Process.pdf

https://www.geeksforgeeks.org/software-testing-strategies/

https://repository.dinus.ac.id/docs/ajar/RPL-Software_Process.pdf

26