• Tidak ada hasil yang ditemukan

REKAYASA PERANGKAT LUNAK FAJRIYAH, S.KOM., M.KOM. STMIK PRABUMULIH

N/A
N/A
Protected

Academic year: 2021

Membagikan "REKAYASA PERANGKAT LUNAK FAJRIYAH, S.KOM., M.KOM. STMIK PRABUMULIH"

Copied!
138
0
0

Teks penuh

(1)

REKAYASA

PERANGKAT

LUNAK

FAJRIYAH, S.KOM., M.KOM. STMIK PRABUMULIH

(2)

REKAYASA

PERANGKAT

LUNAK

(3)

Rekayasa Sistem

 Rekayasa perangkat lunak terjadi sebagai konsekuensi dari suatu

proses yang disebut rekayasa sistem.

 Rekayasa sistem memfokuskan diri pada berbagai elemen, analisis,

perancangan, dan pengorganisasian elemen-elemen tersebut ke dalam suatu sistem yang dapat menjadi sebuah produk, jasa, atau teknologi untuk mentransformasi informasi atau kontrol.

 Proses rekayasa sistem disebut rekayasa informasi bila konteks kerja

rekayasa berfokus pada perusahaan bisnis. Pada saat produk akan dibuat, proses itu disebut rekayasa produk.

(4)

Rekayasa Sistem (2)

 Rekayasa informasi bertujuan menentukan arsitektur yang

memungkinkan suatu bisnis menggunakan informasi secara efektif.

 Rekayasa informasi menghasilkan suatu rencana menyeluruh guna

mengimplementasikan arsitektur- arsitektur berikut : ¤ arsitektur data

¤ arsitektur aplikasi

¤ infrastruktur teknologi,

(5)

Rekayasa Sistem (3)

 Rekayasa produk dimaksudkan untuk

menterjemahkan keinginan pelanggan dengan serangkaian kemampuan yang terbatas ke dalam produk yang dapat bekerja (operasional).

(6)

Lingkup Proyek Perangkat Lunak

¤ Pengembangan perangkat lunak

¤ Pengembangan perangkat lunak, dan pengadaan perangkat keras

¤ Pembenahan sistem prosedur, dan pengembangan perangkat lunak ¤ Pembenahan sistem prosedur,

pengembangan perangkat lunak dan pengadaan perangkat keras

(7)

Rekayasa Perangkat Lunak.. Apa

sih ??

• Inti yang akan dipelajari di RPL adalah

Mempelajari teknik-teknik dan tools yang digunakan dalam pembangunan perangkat lunak

Mata kuliah yang mendasari penguatan pemahaman dalam belajar RPL :

– IMK

– Konsep pemrograman – Algoritma pemrograman – Basisdata

(8)

Definisi Perangkat Lunak

IEEE-Standar Glossary of Software Engineering Terminology, 1990:

(Institute of Electrical and Electronic Engineering )

• Computer programs, procedures, and possibly associated

documentation and data pertaining to the operation of a computer system.

• Terjemahan bebasnya:

Perangkat lunak merupakan kumpulan dari berbagai item

(program, prosedur, dan dokumen data yang saling terkait) yang merepresentasikan masalah di dunia nyata yang

dikonfigurasikan dalam satu bentuk aplikasi yang harus dikerjakan komputer.

(9)

Produk Perangkat Lunak (1)

• Perangkat lunak tidak sama dengan produk

perangkat keras

• Produk perangkat lunak dikembangkan (developed)

atau direkayasa (engineered) Tidak dipabrikkan seperti pabrik perangkat keras, misal komputer, mobil.

• Perangkat lunak secara pemakaian tidak pernah

(10)

Produk Perangkat Lunak (2)

 Perangkat lunak sebagian besar dikembangkan/dibangun

berdasarkan pemesanan hanya sebagian kecil yang dibuat secara paket

Bentuk produk perangkat lunak

Umum/generik

Dibuat untuk keperluan yang luas dan tidak berdasarkan pada permintaan pihak tertentu.

Pesanan/custome/by tailor

Dibuat spesifik sesuai sistem yang dibutuhkan oleh pemesan

(11)

Produk Perangkat Lunak (3)

Karakteristik perangkat lunak yang baik:

- Mempunyai daya guna yang tinggi (usability)

- Mempunyai kinerja sesuai fungsi yang dibutuhkan pemakai - Mampu diandalkan (be reliable)

- Mudah dirawat/diperbaiki (maintenability) - Lebih efisien

- Mempunyai antarmuka yang menarik (eye cathcing user interface) - Mempunyai siklus hidup yang cukup lama (long life time)

(12)

Jenis-jenis Aplikasi PL (1)

Perangkat lunak sistem

Sekumpulan program yang ditulis untuk melayani program-program lain

Misal: sistem operasi, driver, kompilator, interpreter, utility, dll

Perangkat lunak waktu nyata (realtime)

Perangkat lunak yang berfungsi untuk memonitor, menganalisis, mengontrol dan memberikan laporan tentang kejadian dunia

nyata dan meresponnya dalam waktu kurang dari 1 menit. Misal: pengontrol arus udara, pengontrol reaksi nuklir,dll

(13)

Jenis-jenis Aplikasi PL (2)

Perangkat lunak teknik dan ilmu pengetahuan

(scientific & engineering software)

Perangkat lunak yang menangani bidang teknik dan ilmu pengetahuan secara rinci

Misal: simulasi, astronomi, vulkanologi, analisis otomatif, dinamika orbit pesawat ruang angkasa, biologi molekuler, otomasi pabrik, dll

Embeded system

Perangkat lunak yg ditempelkan/dilekatkan pada perangkat lainnya (lunak/keras).

Misal: pada kamera digital, GPS, automobil, microwave, kulkas cerdas, dll

(14)

Jenis-jenis Aplikasi PL (3)

Perangkat lunak pengolah data (data processing)

Perangkat lunak yang khusus digunakan untuk mengolah data dan menghasilkan suatu keputusan tertentu.

Misal: billing telepon, pengolah statistik

Perangkat lunak sistem informasi (information

system)

Perangkat lunak yang mampu memberi informasi dari suatu sistem secara lebih detail.

(15)

Jenis-jenis Aplikasi PL (4)

Perangkat lunak sensor

Perangkat lunak yang mampu mengukur dan mengatur suatu keadaan khusus, kadang digolongkan dalam

embedded system juga.

Misal: pengatur cuaca, pengatur suhu ruangan, dll

Perangkat lunak komunikasi

(communication software)

Perangkat lunak yang berfungsi untuk menghubungkan

atau mengkomunikasikan suatu objek satu dengan lainnya. Misal: router, handphone, dll

(16)

Jenis-jenis Aplikasi PL (5)

Perangkat lunak kantor (offices)

Perangkat lunak yang dirancang untuk membantu tugas-tugas perkantoran.

Misal: word processing, spreedsheet processing, video conferences, dll

Perangkat lunak pengolah grafis

Perangkat lunak yang digunakan untuk melakukan perancangan grafis

(17)

Jenis-jenis Aplikasi PL (6)

Perangkat lunak kecerdasan

Perangkat lunak yang menggunakan algoritma untuk memecahkan masalah kompleks yang tidak sesuai untuk perhitungan atau analisis secara langsung

Misal: sistem pakar, game strategi, jaringan saraf tiruan, dll

(18)

Evolusi Perangkat Lunak (1)

• Perangkat lunak telah semakin berkembang sejak

pertama kali diciptakan tahun 1945

• Fokus utama pembuatannya

Untuk mengembangkan praktik dan teknologi dalam meningkatkan produktivitas para praktisi pengembang PL dan kualitas aplikasi yg dapat digunakan oleh pemakai

• Evolusi dipicu adanya tuntutan bisnis dan

(19)

Evolusi Perangkat Lunak (2)

Era I (1945 – 1960):

- Munculnya teknologi perangkat keras di tahap awal

- Penggunaan perangkat lunak yg berorientasi batch - Distribusi perangkat lunak masih terbatas

- Didominasi perangkat lunak model custome - Munculnya istilah software engineering (akhir 1950- an/awal 1960-an)

- Belum didefinisikan secara jelas tentang aspek software engineering

(20)

Evolusi Perangkat Lunak (3)

Era II (1960 – 1970)

- Disebut era krisis perangkat lunak (software crisis). - Penggunaan perangkat lunak sudah meluas

- Telah hadir perusahaan yang membangun software (software house) - Perangkat lunak sdh mengenal multiprogram, multiuser, real-time, dan penggunaan database.

- Banyak project PL yg gagal: - Over budget/anggaran

- Meledaknya Roket Ariane kesalahan perintah dlm PL Dua konferensi tentang software engineering:

- Disponsori Komite Sains NATO - Tahun 1968 dan 1969

(21)

Evolusi Perangkat Lunak (4)

Era III (1975 – 1985)

- Pengembangan sistem mengarah ke konsep sistem terdistribusi.

- Penerapan sistem embeded intelligence - Harga perangkat keras sudah jauh lebih murah sehingga pemakaian meluas

- Pemanfaatan jaringan global dan lokal serta sudah diperkenalkan komunikasi digital

(22)

Evolusi Perangkat Lunak (5)

Era IV (1985 – 2000)

- Kemampuan PC sudah setara dengan komputer

mainframe

- Penerapan teknologi yang berorientasi pada

objek

- Implementasi sistem pakar, - Jaringan saraf tiruan

- Komputasi paralel

(23)

Evolusi Perangkat Lunak (6)

Era V (2000 – sekarang)

- Penggunaan media digital

- Media web berkembang pesat

- Wireless sudah meluas

- Teknologi meluas hingga di mobile computing,

mobile programming

- Perangkat keras sudah semakin kecil namun

powerfull

- Dilakukan berbagai penelitian yang

menghasilkan model proses/paradigma

pengembangan PL utk mengatasi krisis PL

(24)

Era V (2000 – sekarang)

- Muncul teknik-teknik baru:

- Pemrograman terstruktur

- Pemrograman berientasi objek

- Perangkat bantu pengembangan (CASE tools) - Standarisasi PL

(25)

 Perangkat Lunak adalah suatu aplikasi program komputer

yang di dalamnya terdapat:

 program itu sendiri,

 konfigurasi yang digunakan,

 dokumentasi yang menjelaskan struktur sistem,

 dokumentasi yang menjelaskan bagaimana menggunakan

sistem,

 dan informasi tentang versi terbaru

 Produk Perangkat Lunak dikembangkan sesuai dengan

siapa pemakai perangkat lunak tersebut.

 Produk Perangkat lunak dibagi menjadi:

 Produk Generik, yang dijual pada pasar terbuka

 Produk Spesifik, yang dibuat dan dijual sesuai pesanan dari

pemakai.

(26)

 Software is developed or engineered, not

manufactured

 Software doesn’t “wear out”

 Most software are custom built, not assembled

from existing component

(27)

 Tidak memiliki waktu yang cukup dalam

mengumpulkan data pada proses pembuatan perangkat lunak.

 Ketidakpuasan user pada S/W yang dibuat  Kualitas S/W terkadang meragukan.

 Sulit dalam memaintenance S/W sekarang

Problem dalam Pembuatan

Perangkat Lunak

(28)

 Perangkat Lunak Berdasarkan Pemakai

 Generik: Perangkat lunak yang bisa digunakan

secara umum

 Spesifik: Perangkat lunak yang dibuat

berdasarkan pesanan

 Perangkat Lunak Berdasarkan Fungsional

 Interfacing

 Operating System

 Perangkat Lunak Aplikasi  CASE Tools

Macam-Macam Perangkat

Lunak

(29)

Generik: Perangkat lunak yang digunakan secara umum.

Sebagai contoh:

 Operating System, seperti Microsoft Windows,

 Word Processing, seperti Microsoft Word, WordPad  Spreadsheet, seperti Microsoft Excell

 Beberapa aplikasi khusus bisa dibuat menjadi generik dengan

membuatnya general dan mudah digunakan siapa saja seperti aplikasi akuntansi, aplikasi sekolah, dan lain-lain

Spesifik: Perangkat lunak yang dibuat berdasarkan

pesanan. Banyak Software House yang menghasilkan perangkat lunak ini berdasarkan proyek/pesanan

tertentu. Sebagai contoh: Aplikasi Rumah Sakit, Aplikasi Pendidikan, Aplikasi Kesehatan, dan lain-lain

Perangkat Lunak

(30)

 INTERFACING: Perangkat lunak ini

menghubungkan suatu perangkat keras

tertentu, seperti hardware driver, interfaces dengan perangkat keras lain. Misal:

 Driver untuk Kamera, Handphone atau perangkat

keras lainnya

 Program interface seperti Sensor Suhu dengan

LM555, PPI 8255, Komunikasi Serial RS232.

Perangkat Lunak

(31)

OPERATING SYSTEM: Perangkat lunak yang

menjalankan sistem komputer dan

merupakan interface dari sistem komputer

dan program aplikasi yang berjalan

diatasnya.

Beberapa OS yang dikenal secara luas:

 Microsoft Windows

 Linux dan varians-nya, seperti Redhat, SuSE,

Mandrake, Debian, dsb.  Unix  FreeBSD  Macintosh (Apple)

Perangkat Lunak

Berdasarkan Fungsionalnya

(32)

PROGRAM APLIKASI: program ini

digunakan untuk keperluan tertentu, yang

tujuannya membantu pekerjaan manusia

menjadi lebih mudah. Program ini yang

banyak dibahas dalam pembuatan

perangkat lunak.

Program Aplikasi ini tergantung pada

kebutuhan dari program itu sendiri, seperti:

 Program Office

 Program Graphics Design  Program Multimedia

 dan lain-lain

Perangkat Lunak

(33)

 Perangkat lunak harus memberikan bantuan

dalam merepresentasikan dan mengakses file-file eksternal yang dibuat dengan alat bantu lain.

 Persyaratan Fungsional dan Non-Fungsional  Persyaratan User

 Persyaratan Sistem

 Dokumentasi Persyaratan Perangkat Lunak

(34)

Persyaratan Fungsional: Pernyataan layanan

tentang bagaimana sistem harus bereaksi

terhadap input, sistem harus berlaku pada

situasi-situasi tertentu. Secara khusus

menyatakan apa yang tidak boleh dilakukan

sistem.

Persyaratan Non Fungsional: Pernyataan

tentang batasan layanan dan fungsi yang

diberikan sistem.

Persyaratan Domain: Persyaratan yang

datang dari domain aplikasi sistem dan

merefleksikan karakteristik domain tersebut

Persyaratan Fungsional dan

Non-Fungsional

(35)

Persyaratan Produk: persyaratan yang

diambil dari spesifikasi produk, seperti

persyaratan hardware untuk mendukung

kinerja.

Persyaratan Organisasi: persyaratan yang

berasal dari kebijakan dan prosedur pada

organisasi.

Persyaratan Eksternal: Persyaratan yang

berasal dari faktor eksternal terhadap sistem

dan proses pengembangannya.

(36)

Kecepatan dalam: Transaksi yang diproses/detik,

waktu tanggal user/event atau waktu refresh layar

Ukuran dalam: KB atau jumlah Chip RAM

Kemudahan penggunaan dalam: waktu pelatihan

atau jumlah frame help

Kehandalan dalam: waktu rata-rata kegagalan,

probabilitas ketidaksediaan, kecepatan terjadinya kegagalan, atau ketersediaan

Ketahanan dalam: waktu start ulang setelah

kegagalan, prosentase event yang gagal, atau probabilitas korupsi data

Portabilitas dalam: prosentase pernyataan

tergantung target, atau jumlah sistem target

Ukuran Persyaratan Non

Fungsional

(37)

Mendeskripsikan persyaratan fungsional dan

non-fungsional sehingga dapat dipahami oleh

user yang tidak memiliki pengetahuan teknik.

Persyaratan user harus ditulis memakai bahasa

natural, formal dan diagram intuitif yang

sederhana. Persyaratan user tidak boleh

didefinisikan memakai model implementasi.

Masalah yang sering muncul:

 Tidak Adanya Kejelasan

 Kesimpang-siuran Persyaratan  Penggabungan Persyaratan

(38)

 Persyaratan sistem ini lebih rinci dari

persyaratan user, dan berfungsi sebagai dasar kontrak untuk implementasi sistem.

 Persyaratan sistem ini digunakan sebagai titik

awal perancangan sistem.

 Bahasa natural banyak digunakan dalam

mendefinisikan persyaratan sistem

(39)

Rekayasa Perangkat

Lunak

(40)

 Rekayasa Perangkat Lunak adalah disiplin ilmu

yang membahas semua aspek produksi

perangkat lunak, mulai tahap awal spesifikasi sistem sampai pemeliharaan sistem setelah digunakan.

 Perekayasa Perangkat Lunak memakai

pendekatan yang sistematis dan terorganisir untuk menghasilkan perangkat lunak

berkualitas tinggi.

Definisi Rekayasa

Perangkat Lunak

(41)

 Meningkatkan keakuratan, performance &

efficiency produk secara keseluruhan dalam pengembangan

 Menerapkan metodologi yang terdefinisi

dengan baik untuk resolusi software

Tujuan Rekayasa Perangkat

Lunak

(42)

 Ilmu Komputer berhubungan dengan teori dan

metode yang mendasari sistem komputer dan

perangkat lunak. Teori ini merupakan suatu model fisik dan analitik untuk menyelesaikan kasus yang spesifik.

 Rekayasa Perangkat Lunak berhubungan dengan

masalah-masalah praktis untuk menghasilkan suatu perangkat lunak. Pendekatan dilakukan dengan

model bisnis dan strategi bisnis suatu perangkat lunak.

Perbedaan Rekayasa Perangkat

Lunak dan Ilmu Komputer

(43)

 Rekayasa Sistem berhubungan dengan semua

aspek pengembangan sistem berbasis

komputer, termasuk perangkat keras, perangkat lunak dan rekayasa proses.

 Rekayasa Perangkat Lunak adalah bagian dari

Rekayasa Sistem

Perbedaan Rekayasa Perangkat

Lunak dan Rekayasa Sistem

(44)

 Proses perangkat lunak adalah serangkaian

kegiatan yang tujuannya untuk

mengembangkan atau evolusi perangkat lunak.

 Kegiatan-kegiatan tersebut adalah:

 Spesifikasi perangkat lunak,

 Pengembangan perangkat lunak,  Validasi perangkat lunak,

 Evolusi perangkat lunak

(45)

Model proses perangkat lunak adalah

representasi yang disederhanakan dari

proses perangkat lunak yang

dipresentasikan dari sudut pandang

tertentu

 Paradigma pengembangan model sistem :  Waterfall Development Model

 Evolutionary Development Model  Spiral Development Model

 Incremental Development Model

(46)
(47)

 Development activities are performed in

sequential order, with possibly minor overlap, and minimal or no iteration between activities.

 User needs are determined, requirements are

defined, and the full system is designed, built, and tested for ultimate delivery at one point in time. Some people refer to this as a stage-wise model.

(48)

Pengembangan Eksplorasi:

 Sistem berubah dengan adanya fitur-fitur

tambahan dari user.

Prototype yang dapat dibuang

(Throw-Away):

 Memahami persyaratan user untuk mendapatkan

definisi persyaratan yang lebih baik.

Evolutionary Development

Model

(49)

Evolutionary Development

Model

Penjelasan Garis Besar Spesifikasi Pengembangan Validasi Versi Awal Versi Menengah Versi Akhir

(50)

Masalah-masalah dalam Pengembangan

Evolusioner

 Proses tidak dapat dilihat

 Sistem seringkali mempunyai struktur yang tidak

baik

 Mungkin diperlukan alat bantu khusus

Model pengembangan evolusioner ini

cocok untuk aplikasi yang kecil dan

life-cycle yang pendek.

Evolutionary Development

Model

(51)
(52)

Spiral Model Description

The development spiral consists of four quadrants

Quadrant 1: Determine objectives, alternatives,

and constraints.

Quadrant 2: Evaluate alternatives, identify,

resolve risks.

Quadrant 3: Develop, verify, next-level product.Quadrant 4: Plan next phases.

(53)
(54)

 Proses perangkat lunak dibagi menjadi

serangkaian increment yang dikembangkan secara bergantian.

 Keuntungan Pengembangan Incremental

 User tidak perlu menunggu seluruh sistem dikirimkan,

karena increment pertama mempunyai persyaratan kritis dan perangkat lunak segera dapat digunakan.

 User dapat memakai increment pertama sebagai

prototype

 Resiko kegagalan proyek secara keseluruhan lebih rendah  Pengujian paling ketat diberlakukan pada increment

pertama.

Incremental Development

Model

(55)

 Studi Kelayakan

 Elisitasi dan Analisis Persyaratan  Spesifikasi Persyaratan

 Validasi Persyaratan

Fase Utama Persyaratan

Perangkat Lunak

(56)

Spesifikasi Persyaratan Perangkat Lunak

Studi Kelayakan Elisitasi dan Analisis Persyaratan Spesifikasi Persyaratan Validasi Persyaratan Laporan

Kelayakan Model Sistem

Persyaratan User dan Sistem

Dokumen Persyaratan

(57)

 Perancangan Arsitektural  Spesifikasi Abstrak

 Perancangan Interface  Perancangan Komponen  Perancangan Struktur Data  Perancangan Algoritma

Kegiatan Perancangan

Perangkat Lunak

(58)

Perancangan dan Implementasi

Perangkat Lunak

Spesifikasi Persyaratan Perancangan Arsitektural Spesifikasi Abstrak Perancangan Interface Perancangan Komponen Perancangan Struktur Data Perancangan Algoritma Arsitektur Sistem Spesifikasi Perangkat Lunak Spesifikasi Interface Spesifikasi Komponen Spesifikasi Struktur data Spesifikasi Algoritma

(59)

Validasi Perangkat Lunak

Pengujian Unit Pengujian Modul Pengujian Sub Sistem Pengujian Sistem 1 Pengujian Sistem 2 Pengujian

(60)

Evolusi Perangkat Lunak

Definisi Persyaratan Sistem Nilai Sistem Yang Ada Pengajuan Perubahan Sistem Modifikasi Sistem Sistem

(61)

Metodologi Pengembangan

Perangkat Lunak

 Ketidak efisienan, kurang berhasilnya bahkan kegagalan

pengembangan sistem pada pertengahan tahun 60 sampai 70-an.

 Tidak tersedianya teknik pengembangan perangkat lunak

yang baik.

 Metodologi-metodologi pengembangan perangkat lunak

(62)

Pengembangan perangkat lunak

Pengembangan Perangkat Lunak

proses membuat suatu perangkat lunak baru untuk menggantikan perangkat lunak lama secara keseluruhan atau memperbaiki perangkat lunak yang telah ada.

Metodologi pengembangan perangkat lunak

suatu proses pengorganisasian kumpulan metode dan konvensi notasi yang telah didefinisikan untuk

mengembangkan perangkat lunak.

 suatu strategi pengembangan yang memadukan proses, metode, dan perangkat (tools).

Tujuan  untuk membantu menghasilkan perangkat

(63)

Komponen Metodologi Pengembangan Perangkat Lunak

Menurut Pressman (1997) Komponen metodologi pengembangan perangkat lunak dapat dibagi dalam tiga unit, yaitu :

Metode, yaitu suatu cara atau teknik pendekatan yang sistematik yang

dipergunakan untuk mengembangkan perangkat lunak. Metode ini mencakup : Perencanaan proyek dan perkiraan, analisis keperluan sistem dan perangkat lunak, perancangan struktur data, arsitektur program, prosedur algoritma, Coding, uji coba dan pemeliharaan.

Alat bantu (Tools), yaitu alat-alat (manual atau otomatis) yang

mendukung pengembangan perangkat lunak. Terdapat 2 alat Bantu yang dapat digunakan yaitu : alat Bantu manual dan alat Bantu

otomatis.

Prosedur, yang dipergunakan untuk mendefinisikan urut-urutan

(64)

Daur Hidup Pengembangan Perangkat

Lunak

Phase

Implementasi

Desain

(65)

Tahapan

Tahapan analisis dan perancangan

merupakan tahapan yang paling penting tahapan awal yang penting dalam suatu paradigma pemgembangan perangkat lunak, karena sangat mempengaruhi tahapan selanjutnya

Tahap implementasi perangkat lunak

bertujuan untuk menerapkan spesifikasi kebutuhan perangkat lunak ke dalam bahasa pemrograman tertentu.

Tahap pengujian perangkat lunak

dilakukan untuk menemukan kesalahan (bug) yang mungkin terdapat di dalam sebuah perangkat lunak.

Tahap perawatan perangkat lunak

fokusnya adalah pengubahan.

Ada tiga pengubahan yaitu : pembetulan, adaptasi (perbaikan terhadap lingkungan) dan perluasan (penambahan karena permintaan pemakai).

(66)

Proses Pengembangan Perangkat Lunak

  suatu proses dimana kebutuhan pemakai diterjemahkan menjadi produk

perangkat lunak.

 Proses ini mencakup aktivitas penerjemahan kebutuhan pemakai menjadi

kebutuhan perangkat lunak, transformasi kebutuhan perangkat lunak menjadi desain, penerapan desain menjadi kode program, uji coba kode program, dan instalasi serta pemeriksaan kebenaran perangkat lunak untuk operasional (IEEE. 1990).

 Tahapan proses pengembangan perangkat lunak :

1. Menentukan APA yang harus dikerjakan oleh perangkat lunak dalam

satu rentang waktu tertentu.

2. Mendefinisikan BAGAIMANA perangkat lunak dibuat, mencakup

arsitektur perangkat lunaknya, antar muka internal, algoritma, dan

sebagainya.

3. Penerapan (penulisan program) dan pengujian unit-unit program. 4. Integrasi dan pengujian modul-modul program.

(67)

Siklus Pengembangan Perangkat Lunak

 • Periode waktu yang diawali dengan keputusan untuk

mengembangkan produk perangkat lunak dan berakhir setelah perangkat lunak diserahkan. Umumnya siklus

pengembangan ini terdiri dari tahap analisis kebutuhan, perancangan, penerapan, pengujian, dan instalasi serta pemeriksaan.

 • Periode waktu yang diawali dengan keputusan untuk

mengembangkan produk perangkat lunak dan berakhir saat produk tidak dapat ditingkatkan lebih jauh lagi oleh pengembang.

(68)

Model Pengembangan Perangkat

Lunak

Linier Squensial model

Prototyping Model  MPSI

PROTOTYPING.ppt

RAD Model  MPSI RAD.ppt

(69)

Model Proses Pengembangan Perangkat Lunak

(70)

Cakupan aktivitas :

1. Rekayasa sistem dan Analisis (Sistem Engineering and Analysis)2. Analisis kebutuhan perangkat lunak (Software Requirements

Analysis)

3. Perancangan (Design)4. Pembuatan kode (Coding)5. Pengujian (Testing)

6. Pemeliharaan (Maintenance)

• Corrective Maintenance : Mengoreksi kesalahan pada perangkat lunak,

yang baru terdeteksi pada saat perangkat lunak dipergunakan

• Adaptive Maintenance : Penyesuaian dengan lingkungan baru, misalnya

sistem operasi atau sebagai tuntutan atas perkembangan sistem komputer, misalnya penambahan printer driver

• Perfektive Maintenance : Bila perangkat lunak sukses dipergunakan oleh

pemakai. Pemeliharaan ditujukan untuk menambah kemampuannya seperti memberikan fungsi-fungsi tambahan, peningkatan kinerja dan sebagainya.

(71)

Kelemahan model linear sequential:

 1. Proyek yang sebenarnya jarang mengikuti alur sekuensial

seperti diusulkan, sehingga perubahan yang terjadi dapat menyebabkan hasil yang sudah didapat tim harus diubah kembali/iterasi sering menyebabkan masalah baru.

 2. Linear sequential model mengharuskan semua kebutuhan

pemakai sudah dinyatakan secara eksplisit di awal proses, tetapi kadang-kadang ini tidak dapat terlaksana karena kesulitan yang dialami pemakai saat akan mengungkapkan semua

kebutuhannya tersebut.

 3. Pemakai harus bersabar karena versi dari program tidak akan

didapat sampai akhir rentang waktu proyek.

 4. Adanya waktu menganggur bagi pengembang, karena harus

menunggu anggota tim proyek lainnya menuntaskan pekerjaannya.

(72)

PROTOTYPING

Prototype memberikan ide bagi pembuat atau pemakai potensial tentang cara sistem berfungsi dalam bentuk lengkap.

(73)

Jenis Prototyping

Type I

Langkah-langkahnya :

1. Mengidentifikasikan kebutuhan pemakai

Analis sistem mewawancarai pemakai untuk menentukan apa yang diinginkan pemakai terhadap sistem.

2. Mengembangkan prototyping

Analis sistem menggunakan satu atau lebih alat prototyping untuk mengembangkan prototyping.

cth : - IAG (integrated application generator)

Software system jadi yang mampu menghasilkan semua tampilan yang diinginkan dalam sistem baru.

- Prototyping Toolkits

Mencakup sistem-sistem software terpisah yang masing-masing mampu untuk menghasilkan sebagian tampilan sistem yang diinginkan.

3. Menentukan apakah prototyping dapat diterima

Analis mendidik pemakai dan memberikan kesempatan pada pemakai untuk

membiasakan diri dengan sistem. Jika pemakai dapat menerima sistem, langkah 4 akan diambil. Jika tidak prototyping direvisi dengan mengulangi langkah 1, 2 dan 3.

4. Menggunakan prototyping

(74)

Pengembangan Prototipe Jenis I

1. 2. 3. 4. N Identifikasi Kebutuhan Pengembangan prototipe Prototipe diterima? Y Menggunakan Prototipe

(75)

Jenis Prototyping

Type II

Langkah-langkahnya :

Tiga langkah pertama sama seperti Ptototype Type I. 1. Mengkodekan sistem operasional

Programmer menggunakan prototype sebagai dasar untuk pengkodean (coding) sistem operasional

2. Menguji sistem operasional

3. Menentukan apakah sistem operasional dapat diterima

pemakai memberikan masukan kepada analis apakah sistem dapat diterima. Jika ya, langkah 7 akan diambil. Jika tidak, langkah 4 dan 5 diulangi.

(76)

Pengembangan

Prototipe

Jenis II

N Identifikasi kebutuhan Pengembangan Prototipe Penggunaan Sistem Operasional Prototipe diterima? Sistem diterima? Y Y N Pengkodean Sistem Operasional Menguji Sistem Operasional 1. 2. 4. 5. 6. 7. 3.

(77)

Empat model Prototype :

 Prototype kertas

Gambaran sistem yang dibuat pada media kertas.

Kelemahannya tidak dapat diuji dan diimplementasikan

 Prototype Berbasis PC

Permodelan sistem yang dibuat dengan memanfaatkan media aplikasi-aplikasi untuk presentasi.

 Prototype Kerja

Prototype yang telah mengimplementasikan sebagian dari fungsi sistem.

 Prototype Program

Pada permodelan ini program benar-benar dibuat dan bisa bekerja. Bagian-bagian program yang sudah jadi terus-menerus ditambah dan dilengkapi sampai terbentuk sistem yang diinginkan.

(78)

 Permasalahan sistem yang tidak jelas

Adakalanya user tidak dapat mendefinisikan dengan jelas tentang kebutuhan dan keinginanya terhadap sistem yang akan dikembangkan.

 Kebutuhan dialog user-komputer yang interaktif

Untuk membuat sistem yang menghendaki dialog yang baik dan mudah antara user dan komputer.

 Sistem diminati oleh banyak pemakai

Untuk mencari kesamaan persepsi dari banyak user sehingga dapat diperoleh kesepakatan tentang sistem yang akan dikembangkan.

 User berkeinginan sistem cepat selesai

Untuk mengakomodir keinginan user supaya cepat selesai dan terlihat bentuk kerja sistemnya.

 Kebutuhan user selalu berubah-ubah

User sulit menjelaskan kebutuhannya secara baik sehingga menimbulkan keinginan yanhg selalu berubah-ubah. Untuk itu dapat dibantu dengan memberikan gambaran sistem yang akan dibuat melalui prototype yang diajukan oleh pengembang.

(79)

Potensi Kegagalan Prototyping

 Ketergesaan membuat prototipe mungkin

menghasilkan jalan pintas dalam definisi permasalahan, evaluasi dan dokumentasi.

 Pemakai mungkin sangat tertarik dengan protitipe

tersebut sehingga mereka mengharapkan sesuatu yang tidak realistis dari sistem operasional

 Prototipe jenis I mungkin tidak seefisien sistem

yang dikodekan dalam bahasa pemrograman

 Hubungan komputer-manusia yang disediakan

mungkin tidak mencerminkan teknik perancangan yang baik

(80)

Kelemahan Prototyping :

Pelanggan yang melihat prototype dari

model yang dimintanya tidak menyadari

bahwa mungkin saja prototype dibuat

terburu-buru dan dirancang tidak

tersusun dengan baik

Pengembang kadang-kadang membuat

implementasi sembarangan karena ingin

bekerja dengan cepat.

(81)

Kelebihan Prototyping :

 Peran pemakai sistem dalam pengembangan sistem menjadi

meningkat.

Keterlibatan user tersebut disebabkan adanya evaluasi oleh user berkali-kali untuk mencapai kebutuhan yang diinginkan.

 Sangat membantu penganalisian kebutuhan user

Dengan komunikasi yang intensif, pengembang akan tahu kebutuha pemakai sistem yang sesungguhnya.

 Waktu mengerjakan perangkat lunak dapat menjadi lebih cepat dan

user dapat mengikuti tahapan demi tahapan

 Mempermudah dalam tahap implementasi

Hal ini disebabkan karena user merasa telah mengenal dan memiliki perangkat lunak yang dihasilkan

(82)

METODE PENGEMBANGAN PERANGKAT

LUNAK

Metodologi Rapid Application Development

(RAD)

(83)

RAD ( Rapid Application

Development)

Merupakan

model

proses

pengembangan

perangkat lunak yang menekankan pada siklus

pengembangan yang sangat singkat.

RAD

mengadopsi

model

waterfall

dan

pembangunan dalam waktu yang singkat.

Waktu yang singkat adalah batasan yang penting

dalam model ini

Jika kebutuhan dapat dipahami dengan baik,

proses

RAD

dapat

memungkinkan

tim

pengembang menciptakan Sistem secara utuh

dalam waktu yang sangat pendek (kira-kira 60-90

hari)

(84)

Team #1 Team #2 Team #3 Business Modeling Data Modeling Process Modeling Application Generation Testing & Turnover Business Modeling Data Modeling Process Modeling Application Generation Testing & Turnover Business Modeling Data Modeling Process Modeling Application Generation Testing & Turnover 60-90 hari

RAD Model

(85)

Pendekatan RAD model :

Permodelan bisnis

Untuk menjawab pertanyaan : informasi apa yang mengendalikan proses bisnis? Informasi apa yang dihasilkan? Siapa yang menghasilkan informasi? dan Siapa yang mengolah informasi?  Kebutuhan dari sistem

Permodelan data

Aliran informasi yang sudah didefinisikan disusun menjadi sekumpulan objek data. Ditentukan karakteristik/atribut dan hubungan antar objek data tersebut  Analisis kebutuhan dan data

Permodelan proses

Objek data yang sudah didefinisikan diubah menjadi aliran informasi yang diperlukan untuk menjalankan fungsi-fungsi bisnis.

Pembuatan aplikasi

RAD menggunakan komponen program yang sudah ada atau membuat komponen yang bisa digunakan kembali selama diperlukan

Pengujian dan pergantian

Karena meggunakan komponen yang sudah ada, maka kebanyakan komponen sudah melalui tahap pengujian. Hanya komponen baru yang harus diuji.

(86)

Kelemahan RAD model :

 Tidak cocok untuk proyek skala besar, karena

membutuhkan sumber daya yang cukup untuk membentuk sejumlah tim RAD

 RAD membutuhkan pengembang dan pemakai yang

mempunyai komitmen untuk melaksanakan aktivitas melengkapi sistem dalam kerangka waktu yang singkat, karena proyek bisa gagal akibat waktu yang disepakati tidak terpenuhi.

 Akan menimbulkan masalah jika sistem tidak dapat

dibuat secara modular.

 RAD tidak cocok digunakan untuk sistem yang

(87)

 Waktu pengembangan yang singkat

 Bagi pengembang proses pengerjaan menjadi

lebih mudah karena pengerjaan dibagi dalam tim-tim permodular, sehingga dapat terfokus dalam satu permasalahan.

 Pada tahap pengujian, waktu yang digunakan

dapat dipersingkat karena RAD menekankan pada pemakaian kembali komponen yang sudah ada, sehingga komponen baru saja yang harus diuji.

(88)

SPIRAL MODEL

METODE PENGEMBANGAN

PERANGKAT LUNAK

(89)

SPIRAL MODEL

Merupakan model proses perangkat lunak yang memadukan wujud perulangan dari model

prototyping dengan aspek pengendalian dan sistematika dari waterfall model, dengan

(90)
(91)

Aktivitas didalam Model Spiral

Komunikasi Pemakai (Customer Communication)

Membangun komunikasi yang baik dengan pengguna sistem.

Perencanaan (Planning)

Penentuan tujuan, alternatif dan batasan.

Analisis resiko (Risk Analysis)

Analisis alternatif dan identifikasi / pemecahan resiko

Rekayasa (Engineering)

Pembangunan contoh-contoh aplikasi, misalnya prototype.

Pembangunan & Realisasi (Construction & Release)

Pembangunan sistem, test, install dan support

Evaluasi Pemakai (Customer Evaluation)

Penilaian terhadap hasil dari fase rekayasa dan fase pembangunan & realisasi oleh pengguna.

(92)

Bentuk spiral memberikan gambaran

bahwa semakin besar iterasinya, maka menunjukkan makin lengkap versi dari perangkat lunak yang dibuat.

(93)

Kelemahan Model Spiral

Sulit untuk meyakinkan pemakai (saat

situasi kontrak) bahwa penggunaan pendekatan ini akan dikendalikan

Memerlukan tenaga ahli untuk

memperkirakan resiko, dan harus mengandalkannya supaya sukses

Belum terbukti apakah metode ini cukup

(94)

Keuntungan Model Spiral

Pada model spiral, resiko sangat

dipertimbangkan. Resiko adalah sesuatu yang mungkin mengakibatkan kesalahan.Model spiral merupakan pendekatan yang

realistik untuk pengembangan perangkat lunak / sistem berskala besar.

Pengguna dan pembangun bisa memahami dengan baik perangkat lunak yang dibangun karena setiap kemajuan yang dicapai

(95)

in conjunction with

Software Engineering: A Practitioner’s Approach,

6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005

95

Metode Pengembangan Sistem Dinamis

(Dynamic Systems Development Method)

Dipromosikan oleh konsorsium DSDM (www.dsdm.org)DSDM—karakter yang membedakan

Mirip dalam banyak dengan XP dan/atau ASDSembilan prinsip-prinsip panduan :

Pelibatan user secara aktif adalah keharusan.

Tim DSDM harus diberdayakan untuk mengambil keputusan.

Fokus pada penyajian produk sesering mungkin.

Penerimaan dari tujuan bisnis adalah kriteria esensial untuk penerimaan penyajian.

Pengembangan bertahap dan berulang dibutuhkan untuk fokus pada solusi bisnis yang

akurat.

Semua perubahan selaman pengembangan dapat dibalik.

Kebutuhan adalah dasar pada level tinggi

(96)

96

Dynamic Systems Development Method

(97)

97

Scrum

 Diusulkan oleh Schwaber dan Beedle  Scrum—Karakter yang membedakan

Kerja pengembangan dipartisi menjadi “paket”

Pengujian dan dokumentasi berjalan seiring dengan konstruksi produk

Kerja terjadi dalam “Sprint” dan diturunkan dari “backlog” kebutuhan yang ada

Pertemuan sangat pendek dan beberapa kali diadalah tanpa kursi

“Demo” ditunjukkan pada konsumen dengan alokasi time-box

(98)

in conjunction with

Software Engineering: A Practitioner’s Approach,

6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005

98

Scrum

(99)

in conjunction with

Software Engineering: A Practitioner’s Approach,

6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005

99

Crystal

 Diusulkan Cockburn dan Highsmith  Crystal—karakter yang membedakan

 Secara aktual sebuah model proses keluarga yang memungkinkan manuver berdasar karakteristik permasalahan

 Komunikasi tatap muka ditekankan

 Menyarankan penggunaan workshop refleksi untuk review kebiasaan kerja tim

(100)

in conjunction with

Software Engineering: A Practitioner’s Approach,

6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005

100

Feature Driven Development

 Diusulkan oleh Peter Coad et al

 FDD—karakter yang membedakan

 Penekanan pada definisi “features”

a feature “is a client-valued function that can be implemented in two weeks or less.”

 Menggunakan template feature

 <action> the <result> <by | for | of | to> a(n) <object>

 Daftar feature dibuat dan “perencanaan berdasar “feature” dilakukan

(101)

in conjunction with

Software Engineering: A Practitioner’s Approach,

6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005

101

Feature Driven Development

(102)

in conjunction with

Software Engineering: A Practitioner’s Approach,

6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005

102

Agile Modeling

 Diusulkan oleh Scott Ambler

 Menyarankan prinsip2x agile modeling

 Model dengan sebuah tujuan  Menggunakan banyak model

 Isi lebih penting dari representasi

 Mengetahui model dan tool yang digunakan untuk membuatnya

(103)

MANAJEMEN PROYEK PERANGKAT LUNAK

Proses-proses Dalam Manajemen Proyek

1.

Satuan Ukuran Produktivitas

2.

Satuan Ukuran Kualitas Parangkat Lunak

(104)

Proses-proses Dalam Manajemen Proyek

 Manajemen proyek merupakan lapisan pertama dalam

proses rekayasa perangkat lunak skala besar.

 Untuk menuju pada proyek yang berhasil, perlu

dimengerti tentang :

 • Lingkup pekerjaan

 • Resiko yang dapat ditimbulkan  • Sumber-sumber yang diperlukan  • Tugas yang harus dilaksanakan  • Patokan yang harus diikuti

 • Usaha atau biaya yang dikeluarkan  • Dan Penjadwalan

(105)

Awal Proyek Perangkat Lunak

 Untuk mengestimasi biaya, pembagian tugas,

dan penjadwalan, sebelum sebuah proyek direncanakan perlu :

• Memastikan tujuan dan ruang lingkup

• Memperhatikan alternatif-alternatif solusi • Identifikasi batasan teknik dan manajerial

(106)

Pengukuran dan Satuan Ukuran

 Pengukuran dan satuan ukuran akan membantu

untuk mengerti proses-proses dalam pengembangan produk dan produk itu sendiri. Proses dan produk diukur dalam usaha untuk meningkatkan kualitasnya.

(107)

Estimasi

Dalam aktifitas utama proyek yaitu perencanaan, dilakukan estimasi :

• Sumber daya manusia (ukuran orang/bulan) • Jangka waktu kronologis (Ukuran waktu kalender)

(108)

Analisis Resiko

 Analisis resiko sangat penting dalam manajemen proyek

perangkat lunak. Beberapa hal yang harus diperhatikan berkaitan dengan resiko adalah ;

• Masa yang akan datang : resiko apa yang mempengaruhi trend (kecenderungan) proyek perangkat lunak

• Perubahan : Bagaimana perkembangan dunia mempengaruhi keawetan dan kesuksesan perangkat lunak

• Pilihan : metode apa yang dipakai, berapa orang diperlukan, seberapa tinggi kualitas perangkat lunak dan sebagainya

(109)

 Analsis resiko merupakan serangkaian langkah

untuk menyiasati resiko, yaitu : • Identifikasi resiko

Identifikasi resiko melist semua resiko sesuai dengan kategori(secara makro) sebagai berikut :

 1. Resiko proyek : masalah pembiayaan, penjadwalan,

personil, sumber daya, pelanggan dan kebutuhan dikaitkan dengan akibatnya terhadap pelanggan.

 2. Resiko teknis : masalah desain, implementasi,

antarmuka, verifikasi dan pemeliharaan.

 3. Resiko bisnis : termasuk di dalamnya adalah resiko

(110)

 Salah satu metode terbaik untuk mengerti tiap resiko adalah

dengan sejumlah pertanyaan seperti :

1. Adakah orang-orang yang paling top (The best) ? 2. Sesuaikah keahlian orang-orang tersebut?

3. Cukupkah orang-orang yang tersedia?

4. Apakah staf cukup dapat dipercaya untuk keseluruhan proyek?

5. Akan adakah staf yang bekerja paruh waktu?

6. Apakah staf telah memiliki persepsi yang benar tentang pekerjaannya?

7. Sudah cukupkah pelatihan untuk staf?

8. Cukup rendahkah tingkat pelimpahan kerja untuk menjamin kelanjutan proyek?

(111)

Penjadwalan

 Langkah-langkah yang dilakukan dalam

penjadwalan :

• Identifikasi sekumpulan tugas • Pastikan keterkaitan antar tugas

• Estimasi usaha untuk tiap-tiap tugas

• Tentukan pekerja dan sumber-sumber lainnya • Buat jaringan tugas

(112)

Penelusuran dan Pengendalian

 Penelusuran dan pengendalian dilakukan

setelah ada penjadwalan yang pasti, yaitu memeriksa apakah tugas telah dilaksanakan sesuai dengan jadwal.

(113)

Satuan Ukuran Produktivitas dan Kualitas Perangkat Lunak

 Pengukuran perangkat lunak dilakukan untuk :

• Indikasi kualitas produk

• Perkiraan produktivitas orang-orang yang menghasilkan produk • Perkiraan manfaat dari penerapan metode dan tools

• Membentuk dasar dari estimasi

• Menegaskan (Justify) permintaan tools baru dan pelatihan

 Satuan ukuran perangkat lunak dikategorikan ke dalam :

• Satuan ukuran produktivitas : Output dari proses rekayasa

• Satuan ukuran kualitas : indikasi tingkat pemenuhan kebutuhan konsumen

(114)

 Kategori lain untuk pengukuran :

Pengukuran berorientasi besarnya (Ukuran) :

Besarnya perangkat lunak = jumlah baris program.

Pengukuran berorientasi ukuran merupakan pengukuran langsung. Pengukuran berorientasi ukuran menggunakan tabel berisi data berorientasi ukuran yang merupakan daftar proyek pengembangan perangkat lunak yang telah diselesaikan dikaitkan dengan data berorientasi ukuran untuk proyek yang bersangkutan

(115)

Pengukuran berorientasi fungsi :

fungsi = ruang lingkup informasi dan tingkat kesulitannya Merupakan pengukuran tidak langsung, yang

menitikberatkan pada fungsionalitas atau utilitas program. Disebut juga metode Function Point sesuai dengan informasi-informasi yang didefinisikan:

 o Jumlah masukan dari pemakai  o Jumlah keluaran dari pemakai  o Jumlah penyelidikan dari pemakai  o Jumlah file

(116)

Satuan Ukuran Kualitas Parangkat Lunak

 Kualitas perangkat lunak dihitung pada saat

proses rekayasa perangkat lunak ataupun setelah diserahkan kepada pemakai. Satuan ukuran kualitas perangkat lunak pada saat proses rekayasa :

o Kompleksitas program o Modularitas yang efektif o Besarnya program

(117)

 Definisi pengukuran kualitas menurut Gilb:

• Kebenaran (Correctness) : Program harus bekerja dengan benar. Kebenaran merupakan tingkat perangkat lunak bekerja sesuai

dengan fungsi yang dibutuhkan. Pengukuran yang umum adalah cacat (defect) /KLOC

• Perawatan (Maintainability) : Kemudahan perbaikan jika ada kesalahan, penyesuaian terhadap perubahan lingkungan atau peningkatan sesuai permintaan pemakai

• Integritas (Integrity) : Pengukuran tingkat ketahanan perangkat lunak terhadap serangan (disengaja/tidak) pada program, data dan dokumen

• Kegunaan (Usability) : Berkaitan dengan kemudahan pemakaian yang diukur berdasarkan keahlian yang diperlukan untuk

mempelajari sistem, waktu yang dibutuhkan untuk dapat menggunakan sistem, peningkatan produktivitas dengan

penggunaan sistem dan perkiraan yang sifatnya subjektif pada kelakuan pemakai

(118)

 Menurut Basili dan Zelkowitz ada 5(lima) faktor yang

mempengaruhi produktivitas perangkat lunak :

• Faktor manusia : jumlah dan tingkat keahlian tim

• Faktor masalah : Tingkat kerumitan masalah yang harus dipecahkan

• Faktor proses : Teknik analisis dan desain, bahasa dan tools

• Faktor produk : keandalan dan performansi sistem berbasis komputer

• Faktor sumber daya : ketersediaan tools, sumber-sumber perangkat keras dan perangkat lunak

(119)

PENGUJIAN PERANGKAT LUNAK Pengertian Pengujian

1.

Tujuan Pengujian

2.

Tahap-tahap Pengujian

3.

Pengujian Tahap Analisis

4.

Pengujian Tahap Perancangan

5.

Pengujian Tahap Implementasi

6.

Pengujian Tahap Pengujian

(120)

Pengertian Pengujian

 Proses menjalankan dan mengevaluasi sebuah perangkat lunak secara manual maupun otomatis untuk menguji apakah perangkat lunak sudah memenuhi persyaratan atau belum, atau untuk menentukan perbedaan antara hasil yang diharapkan dengan hasil sebenarnya.

(121)

 Beberapa prinsip pengujian yang harus

diperhatikan.

1. Dapat dilacak hingga ke persyaratan atau dokumen SRS

2. Pengujian harsu direncanakan sebelum pelaksanaan pengujian

3. Pengujian harus dimulai dari hasl yang kecil, diteruskan ke hal-hal yang besar.

4. Pengujian yang berlebihan tidak akan mungkin dapat dilaksanakan

(122)

Tujuan Pengujian

1. Menilai apakah perangkat lunak yang

dikembangkan telah memenuhi kebutuhan pemakai. 2. Menilai apakah tahap pengembangan perangkat

lunak telah sesuai dengan metodologi yang digunakan.

3. Membuat dokumentasi hasil pengujian yang

menginformasikan kesesuaian perangkat lunak yang diuji dengan spesifikasi yang telah ditentukan.

(123)

Tahap-tahap Pengujian

1. Tentukan apa yang akan diukur melalui pengujian 2. Bagaimana pengujian akan dilaksanakan

3. Membangun suatu kasus uji (test case), yaitu

sekumpulan data atau situasi yang akan digunakan dalam pengujian.

4. Tentukan hasil yang diharapkan atau hasil sebenarnya

5. Jalankan kasus pengujian

6. bandingkan hasil pengujian dan hasil yang diharapkan.

(124)

Pengujian Tahap Analisis

 Pengujian pada tahap analisis ditekankan pada

validasi terhadap kebutuhan, untuk menjamin bahwa kebutuhan telah dispesifikasikan dengan benar.

 Tujuan pengujian pada tahap ini adalah untuk

mendapatkan kebutuhan yang layak dan untuk memastikan apakah kebutuhan tersebut sudah dirumuskan dengan baik.

(125)

 Faktor-faktor pengujian yang dilakukan pada

tahap analisis ini meliputi :

1. Kebutuhan yang berkaitan dengan metodelogi 2. Pendefinisian spesifikasi fungsional

3. Penentuan spesifikasi kegunaan 4. Penentuan kebutuhan portabilitas 5. Pendefinisian antar muka sistem.

(126)

Pengujian Tahap Perancangan

 Pengujian tahap perancangan bertujuan untuk menguji

struktur perangkat lunak yang diturunkan dari kebutuhan. Kebutuhan yang bersifat umum dirinci menjadi bentuk yang lebih spesifik .

 Faktor-faktor pengujian yang dilakukan pada tahap

perancangan meliputi :

1. Perancangan yang berkaitan dengan kebutuhan

2. Kesesuaian perancangan dengan metodologi dan teori. 3. Portabilitas rancangan

4. Perancangan yang dirawat

5. Kebenaran rancangan berkaitan dengan fungsi dan aliran data.

(127)

Pengujian Tahap Implementasi

 Pengujian pada tahap ini merupakan pengujian

unit-unit yang dibuat sebelum diintegrasikan mejadi aplikasi keseluruhan.

 Faktor-faktor pengujian yang dilakukan pada tahap

implementasi meliputi : 1. Kendali integritas data 2. Kebenaran program 3. kemudahan pemakaian 4. Sifat coupling

(128)

Pengujian Tahap Pengujian

 Tujuan pengujian pada tahap ini adalah untuk

menilai apakah spesifikasi program telah ditulis menjadi instruksi-instruksi yang dapat dijalankan pada mesin. Selain itu, juga untuk menilai apakah instruksi yang ditulis tersebut telah sesuai dengan spesifikasi program.

 Faktor-faktor pengujian yang dilakukan pada tahap

ini meliputi :

1. Pengujian fungsional 2. Dukungan manual 3. Kemudahan operasi.

(129)

Pengujian dengan Kasus Uji

 Pengujian yang dilakukan meliputi pengujian

unit (berupa prosedur atau fungsi) dan

pengujian sistem. Dalam pengujian unit, unit-unit yang diuji meliputi unit-unit-unit-unit yang ada dalam sistem.

 Sedangkan pengujian sistem dilakukan

terhadap sistem secara keseluruhan. Setiap pengujian dilakukan dengan menggunakan berbagai data masukan, baik data yang valid maupun tidak.

(130)

Teknik Pengujian

 Ada dua teknik pengujian yang dapat digunakan untuk

menguji perangkat lunak, yaitu

1. black box testing

(131)

Pengujian Black Box

 Pengujian black box digunakan untuk menguji

fungsi-fungsi khusus dari perangkat lunak yang dirancang.

 kebenaran perangkat lunak yang diuji hanya dilihat

berdasarkan keluaran yang dihasilkan dari data atau kondisi masukan yang diberikan untuk fungsi yang ada tanpa melihat bagaimana proses untuk mendapatkan keluaran tersebut.

 Dari keluaran yang dihasilkan, kemampuan program

dalam memenuhi kebutuhan pemakai dapat diukur sekaligus dapat diiketahui kesalahan-kesalahannya.

(132)

 Beberapa jenis kesalahan yang dapat diidentifikasi :

• Fungsi tidak benar atau hilang • Kesalahan antar muka

• Kesalahan pada struktur data (pengaksesan basis data)

• Kesalahan inisialisasi dan akhir program • Kesalahan performasi.

 Walaupun sulit untuk menelusuri kesalahan yang

mungkin didapat, teknik pengujian black box lebih sering dipilih untuk menguji perangkat lunak karena kemudahan dalam pelaksanaannya.

(133)

Pengujian White Box

 Berbeda dengan teknik black box teknik ini

digunakan untuk mengetahui cara kerja suatu perangkat lunak secara internal.

 Pengujian dilakukan untuk menjamin

operasi-operasi internal sesuai dengan spesifikasi yang telah ditetapkan dengan menggunakan struktur kendali dari prosedur yang dirancang.

(134)

 Pelaksanaan pengujian white box :

• Menjamim seluruh independent path dieksekusi paling sedikit satu kali. Independent path adalah jalur dalam program yang menunjukkan paling sedikit satu kumpulan proses ataupun kondisi baru.

• Menjalani logical decision pada sisi dan false

• Mengeksekusi pengulangan (looping) dalam batas-batas yang ditentukan

(135)

Strategi Pengujian

Digunakan

untuk

mengintegrasikan

metode-metode

perancangan

kasus

pengujian perangkat lunak menjadi suatu

langkah-langkah terencana dengan tujuan

mendapatkan perangkat lunak yang sukses.

Setiap strategi pengujian perangkat lunak

harus meliputi perencanaan pengujian,

perancangan kasus-kasus uji, eksekusi

pengujian,

pengumpulan

data,

serta

evaluasi.

(136)

1.

Pengujian unit program

Pengujian difokuskan pada unit

terkecil dari suatu modul program.

Dilaksanakan dengan menggunakan

driver dan stub. Driver adalah suatu

program utama yang berfungsi

mengirim atau menerima data kasus

uji dan mencetak hasil dari modul

yang diuji. Stub adalah modul yang

menggantikan modul sub-ordinat dari

modul yang diuji.

(137)

2. Pengujian integrasi

Pengujian terhadap unit-unit program yang

saling berhubungan (terintegrasi) dengan fokus

pada masalah interfacing. Dapat dilaksanakan

secara top-down integration atau bottom-up

integration.

3. Pengujian validasi

Pengujian ini dimulai jika pada tahap integrasi

tidak ditemukan kesalahan. Suatu validasi

dikatakan sukses jika perangkat lunak berfungsi

pada suatu cara yang diharapkan oleh pemakai.

(138)

4. Pengujian sistem

Pengujian yang dilakukan sepenuhnya pada

sistem berbasis komputer.

• Recovery testing

Pengujian dilakukan dimana sistem diusahakan untuk gagal, kemudian diuji normalisasinya.

• Security testing

Dilakukan untuk menguji mekanisme proteksi

• Stess testing

Pengujian yang dirancang untuk menghadapkan suatu perangkat lunak kepada situasi Yang tidak normal.

Referensi

Dokumen terkait

 Rekayasa perangkat lunak dimulai dg serangkaian tugas pemodelan yg membawa pd suatu spesifikasi lengkap dari persyaratan dan representasi desain yg komprehensif bagi S/W yg

- Komponen partial-experience Aplikasi, kode, desain, atau data pengujiaan yang ada pada proyek yang lalu yang dihubungkan dengan perangkat lunak yang dibangun untuk

Ranah keilmuan Program Studi S1 Rekayasa Perangkat Lunak meliputi ilmu pada area Ilmu Komputer atau Informatika, Rakayasa Perangkat Lunak, dan Sistem Komputer sehingga

Perangkat lunak bahasa yaitu program yang digunakan untuk menerjemahkan instruksi- instruksi yang ditulis dalam bahasa pemrograman ke bahasa mesin dengan aturan atau prosedur

Perencanaan proyek rekayasa perangkat lunak membahas berbagai tindakan atau pekerjaan yang perlu dilakukan oleh semua yang terlibat di dalam proyek, termasuk dokumen- dokumen

Perencanaan proyek rekayasa perangkat lunak membahas berbagai tindakan atau pekerjaan yang perlu dilakukan oleh semua yang terlibat di dalam proyek, termasuk

Disiplin ilmu rekayasa atau teknik yang berkaitan dengan semua aspek dalam membuat perangkat lunak.?. Software Process Serangkaian aktifitas yang tujuannya adalah pembangunan atau

Context Diagram Context Diagram adalah data flow diagram tingkat atas DFD Top Level, yaitu diagram yang paling tidak detail, dari sebuah sistem atau perangkat lunak yang menggambarkan