Transcript No Slide Title

DEFINISI
 REKAYASA PERANGKAT LUNAK SANGAT BERKAITAN
DENGAN PENGEMBANGAN PERANGKAT SISTEM OLEH
TIM (KELOMPOK)
 REKAYASA PERANGKAT LUNAK MEMANFAATKAN
PRINSIP-PRINSIP REKAYASA DALAM PENGEMBANGAN
PERANGKAT LUNAK
 BAIK ASPEK TEKNIS
 DEVIDE & CONQUER
 MAUPUN NONTEKNIS
 MANAJEMEN PROYEK
RPL BERKAITAN DENGAN:
 TEORI
 METODA
 ALAT-ALAT (TOOLS)
UNTUK PENGEMBANGAN PERANGKAT LUNAK
REKAYASA PERANGKAT LUNAK HARUS MENGHASILKAN
PRODUK YANGEKONOMIS
 HANDAL
 BEKERJA EFISIEN
1
LATAR BELAKANG
 PEREKAYASA PERANGKAT LUNAK HARUS MENGUASAI
 TEKNOLOGI KOMPUTER
 ILMU DASAR KOMPUTER
 PENGETAHUAN PERANGKAT KERAS
 TEKNOLOGI PENGEMBANGAN PERANGKAT LUNAK
 TEORI
 METODOLOGI
 ALAT-ALAT (TOOLS)
 KEMAMPUAN BERKOMUNIKASI
 LISAN
 TERTULIS
 MANAJEMEN PROYEK
 PEMBAGIAN TUGAS & TANGGUNG JAWAB DI DALAM KELOMPOK
 KENDALI WAKTU & BIAYA
 MEMAHAMI KESULITAN YANG DIHADAPI USER
 AWAM DENGAN TEKNOLOGI & METODOLOGI
2
LATAR BELAKANG
 PERANGKAT LUNAK BUKAN HANYA PROGRAM, TETAPI JUGA DOKUMENTASI UNTUK
 MEMASANG (INSTALL)
 APA YANG DIBUTUHKAN
 PERANGKAT KERAS
 PERANGKAT LUNAK
 KONDISI YANG HARUS DIPERSIAPKAN
 PROSEDUR YANG HARUS DIKERJAKAN
 LANGKAH-LANGKAH YANG DIPERLUKAN
 APA YANG BOLEH & APA YANG TIDAK BOLEH
 MEMAKAI (USE)
 PRAKONDISI
 APA YANG PERLU DILAKUKAN SEBELUM MEMAKAI
 POSKONDISI
 APA YANG PERLU DILAKUKAN SESUDAH MEMAKAI
 MENGEMBANGKAN (DEVELOP)
 APA KEBUTUHAN USER SAAT DIKEMBANGKAN
 APA TUJUAN SISTEM
 APA YANG TELAH DICAPAI
 APA YANG BELUM DICAPAI
 MERAWAT (MAINTAIN)
 UMUR PAKAI
 SYARAT PENYIMPANAN
 PERUBAHAN YANG MUNGKIN DILAKUKAN
 PERUBAHAN YANG TIDAK MUNGKINA DILAKUKAN
3
LATAR BELAKANG
 TUJUAN REKAYASA PERANGKAT LUNAK
MENGHASILKAN PRODUK PL YANG, DITINJAU DARI SEGI BIAYA, SANGAT EFISIEN
 BILA BIAYA TAK TERBATAS SECARA TEORITIS APAPUN DAPAT DIKERJAKAN
 TANTANGAN PEREKAYASA PERANGKAT LUNAK
MENGHASILKAN PL YANG BERKUALITAS TINGGI
DENGAN
 SUMBER DAYA TERBATAS
 DAN JANGKA WAKTU YANG TERTENTU
4
LATAR BELAKANG
 CIRI PERANGKAT LUNAK YANG DIREKAYASA DENGAN BAIK
 MUDAH DIRAWAT
 DILENGKAPI DOKUMENTASI
 PERUBAHAN DAPAT DILAKUKAN DENGAN BIAYA MINIMUM
 DAPAT DIANDALKAN
 BEKERJA SEPERTI YANG DIHARAPKAN
 GAGAL HANYA BILA KELUAR DARI SPESIFIKASINYA
 BEKERJA EFISIEN
 TIDAK MEMBOROSKAN SUMBER DAYA
 MEMORY
 PROSESOR
 PENYIMPANAN
 DLL
 MEMPUNYAI ANTAR MUKA PEMAKAI YANG BAIK
 DIBUAT SESUAI DENGAN TINGKAT KEMAMPUAN PEMAKAI
5
LATAR BELAKANG
 PRODUK PERANGKAT LUNAK DIKEMBANGKAN DARI SERANGKAIAN PERUBAHAN
 DARI USER REQUIREMENT MENJADI KODE-EKSEKUSI UNTUK MESIN
KEBUTUHAN
USER
BENTUK
RANCANGAN
BAHASA
KOMPUTER
KODE
MESIN
6
LATAR BELAKANG
 REKAYASA PERANGKAT LUNAK BERUPAYA MENGHASILKAN
 KOMPONEN PERANGKAT LUNAK YANG DAPAT DIPAKAI ULANG (REUSABILITY)
 KOMPONEN DIRANCANG DAPAT DIMANFAATKAN PADA BERBAGAI PROGRAM
 MEMPUNYAI
 KOPLING YANG RENDAH
 KOHESI YANG TINGGI
 KOMPONEN PAKAI ULANG (REUSABLE COMPONENT)
BERISI ALGORITMA
BERISI
SUBROUTINE
ALGORITMA &
STRUKTUR DATA
OBJECT/
CLASS
7
LATAR BELAKANG
 REKAYASA PERANGKAT LUNAK MENGHASILKAN PRODUK BERBENTUK
 PERANGKAT LUNAK LENGKAP DENGAN DOKUMENTASINYA
 DUA MACAM PRODUK PERANGKAT LUNAK
PRODUK YANG DIKEMBANGKAN
UNTUK DIJUAL KEPADA PUBLIK
GENERIK
PRODUK YANG DIKEMBANGKAN
KHUSUS UNTUK SEBUAH PERUSAHAAN
SPESIFIK
8
APLIKASI PERANGKAT LUNAK
 SYSTEM SOFTWARE
 PROGRAM UNTUK MENGATUR/MELAYANI PROGRAM-PROGRAM LAIN
 BANYAK BERINTERAKSI DENGAN PERANGKAT KERAS
 REAL-TIME SOFTWARE
 PERANGKAT LUNAK YANG:
 MEMONITOR
 MENGANALISA
 MENGENDALIKAN
KEJADIAN/PERISTIWA YANG SEDANG TERJADI
 WAKTU TANGGAP(RESPONSE TIME) SINGKAT
 BUSINESS SOFTWARE
 PERANGKAT LUNAK APLIKASI
 PENGGAJIAN
 PENJUALAN
 PERSEDIAAN BARANG
 DLL
 KADANG TERPADU MENJADI SATU
MILIDETIK
SIM
9
APLIKASI PERANGKAT LUNAK
 ENGINEERING & SCIENTIFIC SOFTWARE
 APLIKASI PERANGKAT LUNAK YANG BANYAK MEMPROSES ANGKA-ANGKA
 ASTRONOMI
 OTOMOTIF
 PERAMALAN CUACA
 BIOLOGI
 DLL
 EMBEDDED SOFTWARE
 PERANGKAT LUNAK YANG TERSIMPAN DALAM ROM
 MENGATUR PERANGKAT KERAS
 MESIN CUCI
 MICROWAVE
 LEMARI PENDINGIN
 DLL
10
APLIKASI PERANGKAT LUNAK
 PERSONAL COMPUTER SOFTWARE
 SANGAT BANYAK
 SANGAT BERAGAM
 PENGOLAH KATA
 LEMBAR KERJA ELEKTRONIK
 BASIS DATA
 HIBURAN
 DLL
 ARTIFICIAL INTELLIGENT SOFTWARE
 MEMANFAATKAN NONNUMERICAL ALGORITMA
 BIDANG PEMANFAATAN
 PATERN RECOGNITION
 PENGENALAN POLA BENTUK
 EXPERT SYSTEM
 SISTEM PAKAR
 NEURAL NETWORK
 JARINGAN SYARAF TIRUAN
11
MITOS TENTANG PERANGKAT LUNAK
 BANYAK PERMASALAHAN PADA SEBUAH PERANGKAT LUNAK DATANG DARI
ASUMSI-ASUMSI YANG KEBENARANNYA TIDAK DAPAT DIPERTANGGUNG JAWABKAN
 TIGA KELOMPOK YANG TERKAIT DALAM PENGEMBANGAN PERANGKAT LUNAK
 MANAGEMENT (MANAJEMEN)
 MANAJER PENGEMBANGAN PL HARUS
 MENGATUR ANGGARAN
 MENJAGA JADWAL DARI KELAMBATAN
 MENINGKATKAN KUALITAS
 CUSTOMER (PEMAKAI)
 YANG MENGINGINKAN PL DIKEMBANGKAN
 REKAN KERJA
 BAGIAN LAIN
 PEMASARAN
 PERSONALIA
 PEMBUKUAN
 DLL
 PIHAK LUAR, BERDASARKAN KONTRAK KERJA
 PRACTITIONER (PENGEMBANG)
 YANG MENGEMBANGKAN PL
 DIANTARANYA PROGRAMMER
12
MITOS TENTANG PERANGKAT LUNAK
 MITOS DIPIHAK MANAJEMEN
 MITOS
 ADANYA PANDUAN & PROSEDUR, PASTI LANCAR
 KENYATAAN
 APAKAH:
 DISADARI KEBERADAANNYA ?
 LENGKAP ?
 DIPAKAI ?
 SESUAI KEBUTUHAN ?
 MITOS
 PERALATAN BARU & MODERN
 KENYATAAN
 PENGUASAAN TOOL LEBIH PENTING DARI HARDWARE/SOFTWARE
 MITOS
 BILA TERLAMBAT, TAMBAH PROGRAMMER
 KENYATAAN
 TAMBAH PROGRAMMER AKAN SEMAKIN LAMBAT
13
MITOS TENTANG PERANGKAT LUNAK
 MITOS DIPIHAK PEMAKAI
 MITOS
 TUJUAN SISTEM SECARA UMUM CUKUP UNTUK MEMBUAT PL, RINCIAN
BELAKANGAN SAJA SAAT PROGRAM DIKEMBANGKAN
 KENYATAAN
 RINCIAN KEBUTUHAN SANGAT PENTING
 FUNGSI
 PERFORMANCE
 ANTAR-MUKA
 BATASAN RANCANGAN
 KRITERIA VALIDASI
 DLL
 HANYA BISA DIPEROLEH DENGAN KOMUNIKASI YANG INTENSIF
 MITOS
 PERANGKAT LUNAK BERSIFAT FLEKSIBEL
 PERUBAHAN KEBUTUHAN MUDAH DIAKOMODASI OLEH PENGEMBANG PL
 KENYATAAN
 DAMPAK SANGAT BERGANTUNG PADA TAHAP MANA PERUBAHAN TERJADI
14
MITOS TENTANG PERANGKAT LUNAK
 MITOS DIPIHAK PENGEMBANG
 MITOS
 PROGRAM SELESAI, PEKERJAAN SELESAI
 KENYATAAN
 50% - 70% USAHA DIHABISKAN SETELAH PROGRAM DISERAHKAN
KE USER UNTUK PERTAMA KALINYA
 MITOS
 KUALITAS HANYA BISA DIKETAHUI SETELAH PROGRAM BERJALAN (RUNNING)
 KENYATAAN
 KUALITAS DAPAT DIJAGA SEJAK PL DIKEMBANGKAN
 MITOS
 YANG DISERAHKAN KE USER ADALAH PROGRAM
 KENYATAAN
 YANG DISERAHKAN ADALAH KONFIGURASI PERANGKAT LUNAK
 PROGRAM DITAMBAH DOKUMENTASI
15
AKTIFITAS MENGHASILKAN PL
 KEGIATAN YANG DILAKUKAN OLEH PEREKAYASA PERANGKAT LUNAK
 ADA BANYAK METODOLOGI
 BISA MEMANFAATKAN BANTUAN CASE
 COMPUTER AIDED SOFTWARE ENGINEERING
 ALAT BANTU AKTIFITAS PENGEMBANGAN PERANGKAT LUNAK
 SECARA UMUM ADA 4 AKTIFITAS UTAMA
SPESIFIKASI
 TENTANG KEMAMPUAN PERANGKAT LUNAK
 BERISI BATASAN OPERASIONAL
PENGEMBANGAN
 TAHAP MENGEMBANGKAN SESUAI SPESIFIKASI
VALIDASI
 TAHAP PENGUJIAN AGAR SESUAI SPESIFIKASI
EVOLUSI
 PENYESUAIAN MENGIKUTI PERUBAHAN KEBUTUHAN
16
WATERFALL MODEL
DEFINISI
KEBUTUHAN
SISTEM
RANCANG
SISTEM
IMPLEMENTASI
&
UNIT TESTING
INTEGRASI
&
SYSTEM TESTING
OPERASI
&
PERAWATAN
17
WATERFALL MODEL
 ANALISA & DEFINISI KEBUTUHAN SISTEM
DIURAIKAN TENTANG
 KEMAMPUAN
 BATASAN
 TUJUAN
SISTEM
 RANCANG SISTEM & PERANGKAT LUNAK
 TRANSFORMASI KEBUTUHAN KEBENTUK PERANGKAT LUNAK
 ARSITEKTUR SISTEM
 KEBUTUHAN HARDWARE
 KEBUTUHAN SOFTWARE
 FUNGSI DIURAIKAN
 IMPLEMENTASI & UNIT TESTING
PEMANFAATAN SEBAGAI SEBUAH PERANGKAT LUNAK
 DIBUAT PROGRAM
 DIUJI KESESUAIANNYA
 INTEGRASI & SYSTEM TESTING
PEMBENTUKAN SEBUAH SISTEM
 UNIT-UNIT DIINTEGRASIKAN
 DIUJI SEBAGAI SEBUAH SISTEM
 OPERASI & PERAWATAN
PEMAKAIAN & PENYESUAIAN
 SISTEM DIMANFAATKAN
 PERBAIKAN, PERUBAHAN & PENGEMBANGAN
18
WATERFALL MODEL
DISEBUT JUGA DAUR HIDUP KLASIK
 PARADIGMA YANG SUDAH LAMA SEKALI
 NAMUN TETAP BERTAHAN SAMPAI SAAT INI
 BANYAK YANG MASIH MEMAKAI & TETAP DIANGGAP SESUAI
 PROBLEMA YANG DIHADAPI PARADIGMA INI
 TAHAPAN PROYEK SESUNGGUHNYA TIDAK SEQUENTIAL
 TAHAPAN PROYEK BANYAK MENGALAMI ITERASI/PENGULANGAN
 PADA DASARNYASULIT MENDEFINISIKAN KEBUTUHAN SECARA JELAS
 PADA PARADIGMA INI BENTUK KERJA LAMBAT TERLIHAT
 KESALAHAN DI AWAL TAHAP BERAKIBAT SANGAT FATAL
 PARADIGMA YANG PALING BANYAK DIPAKAI
PALING BANYAK DIIKUTI & DITERAPKAN
 MASIH DIANGGAP SESUAI DENGAN KEADAAN SEKARANG
WALAUPUN DENGAN SEGALA KEKURANGAN YANG DIMILIKI
19
PROTOTYPING
 DIPAKAI BILA DITEMUI KONDISI
 DEFINISI USER BERSIFAT UMUM
 USER TIDAK TAHU PASTI APA YANG DIINGINKAN
 DEFINISI USER BERSIFAT TIDAK RINCI
 USER TIDAK TAHU PASTI APA & BAGAIMANA BENTUK
 MASUKAN
 PROSES
 KELUARAN
 PENGEMBANG MERASA TIDAK PASTI TENTANG
 PILIHAN ALGORITMA YANGAKAN DIPAKAI
 BAGAIMANA LINGKUNGAN SISTEM YANG AKAN DIKEMBANGKAN
 BENTUK, SIFAT & KARAKTERISTIK ANTAR-MUKA PEMAKAI
 INTINYA ADA KETIDAK PASTIAN
 DIPIHAK USER
 TENTANG APA DIINGINKAN
 DIPIHAK PENGEMBANG
 APA YANG HARUS DILAKUKAN
20
PROTOTYPING
EVOLUTIONARY
DIMULAI DARI MODEL
DIKEMBANGKAN
AKHIRNYA DIMANFAATKAN
THROWAWAY
HANYA DIBUAT SEBAGAI MODEL
UNTUK MENCARI BENTUK YANG
DIINGINKAN (CETAK BIRU)
 MACAM
21
PROTOTYPING
DISEBUT
EVOLUTIONARY
PROTOTYPE
TENTUKAN
KEBUTUHAN
BUAT
PROTOTIPE
EVALUASI
TIDAK SESUAI
SESUAI
GUNAKAN
PROTOTIPE
22
PROTOTYPING
THROWAWAY
PROTOTYPE
PROGRAM
SISTEM
TENTUKAN
KEBUTUHAN
UJI
SISTEM
BUAT
PROTOTIPE
EVALUASI
TIDAK
SESUAI
SESUAI
TIDAK
SESUAI
EVALUASI
SESUAI
GUNAKAN
SISTEM
23
PROTOTYPING
4 (EMPAT) MODEL PROTOTIPE
1 PROTOTIPE KERTAS
 GAMBARAN SISTEM DIBUAT PADA MEDIA KERTAS
 TIDAK MEMPUNYAI BAGIAN YANG:
 OPERASIONAL
(BERBENTUK PROGRAM)
 DAPAT DIUJICOBA
(DAPAT DI TEST)
 DAPAT DIIMPLEMENTASIKAN
(DAPAT DI
RUN/EXECUTE)
2 PROTOTIPE BERBASIS PC
 PEMODELAN MEMANFAATKAN PROGRAM APLIKASI
 PROGRAM-PRORAM PRESENTASI
 UNTUK MEMPERLIHATKAN INTERAKSI MANUSIA-KOMPUTER
3 PROTOTIPE KERJA
 IMPLEMENTASI SEBAGIAN FUNGSI SISTEM
 FUNGSI YANG INGIN DILIHAT KARAKTERISTIKNYA
 DIBUATKAN PROGRAMNYA
4 PROTOTIPE PROGRAM
 PROGAM BENAR-BENAR DIBUAT & BISA BEKERJA
 BAGIAN PROGRAM YANG SUDAH BERFUNGSI
 TERUS MENERUS DITAMBAH & DILENGKAPI
24
PROTOTYPING
KEUNGGULAN PROTOTIPE
1 KOMUNIKASI USER - DEVELOPPER
 FREKUENSI KOMUNIKASI MENINGKAT
 PENGEMBANG AKAN SELALU MEMINTA PENDAPAT USER
2 MEMBANTU ANALIS
 MENENTUKAN KEBUTUHAN USER YANG SEBENARNYA
 MEMINIMALKAN SALAH PERSEPSI
3 PERAN USER MENINGKAT
 EVALUASI OLEH USER BERKALI-KALI
 USER BISA MEMBERIKAN MASUKAN SETIAP SAAT
4 PENGEMBANGAN LEBIH CEPAT
 PROGRAM BISA LANGSUNG DIBUAT
 USER MELIHAT PERKEMBANGAN TAHAP DEMI TAHAP
5 IMPLEMENTASI MUDAH
 USER SUDAH MENGENAL PERANGKAT LUNAK YANG DIKEMBANGKAN
 USER TIDAK AKAN MERASA ASING
 SEJAK AWAL USER SUDAH MERASA MEMILIKI
25
PROTOTYPING
KELEMAHAN PROTOTIPE
1 PEMAKAI SIBUK
 USER & PENGEMBANG HARUS SAMA-SAMA MEMILIKI KOMITMEN
 MENYEDIAKAN WAKTU UNTUK BERTEMU
 SAMA-SAMA SEPAKAT UNTUK BEKERJA SAMA
2 PEMAKAI SULIT MELAKUKAN EVALUASI
 BENTUK PROTOTIPE SERING BERUBAH
 DISESUAIKAN DENGAN KEBUTUHAN USER
3 USER INGIN CEPAT SELESAI
 BENTUK PROGRAM SUDAH TERLIHAT SEJAK AWAL
 USER MERASA TIDAK AKAN LAMA LAGI SELESAI
 PENGEMBANG SERING MENGABAIKAN DOKUMENTASI
4 USER BERHARAP TERLALU BANYAK
 KEBERHASILAN MEMBAWA DAMPAK
 SERING EVALUASI & KOMUNIKASI MEMBUAT USER MENJADI
 SERING BERUBAH KEINGINAN
 TIDAK PASTI DENGAN KEBUTUHAN
5 PROTOTIPE BEKERJA TIDAK EFISIEN
 LEBIH MEMENTINGKAN KEBERHASILAN
26
PROTOTYPING
PROTOTYPING BAIK DIPAKAI PADA KEADAAN
1 SISTEM MEMPUNYAI RESIKO TINGI
 TIDAK JELAS PERMASALAHANNYA
 TIDAK JELAS KEBUTUHAN & KEINGINAN
 TIDAK PASTI APA YANG INGIN DILAKUKAN
2 PERANCANGAN DIALOG USER - KOMPUTER
 BAGAIMANA MEMBUAT DIALOG YANG BAIK, RAMAH, MUDAH ?
3 SISTEM DIMINATI OLEH BANYAK PEMAKAI
 MENCARI KESEPAKATAN
 BASIS UNTUK MENYAMAKAN PERSEPSI
4 USER INGIN CEPAT SELESAI
 USER TIDAK SABAR MENUNGGU
 PROTOTIPE SEGERA MEMPERLIHATKAN BENTUK KERJA SISTEM
5 MASA PAKAI SINGKAT
 SISTEM HANYA DIPAKAI BEBERAPA KALI SAJA
6 INGIN MENUNJUKKAN INOVASI
 PENGEMBANG DAPAT MENUNJUKKAN KECANGGIHAN
 SISTEM CEPAT TERLIHAT (MUNGKIN JUGA CEPAT SELESAI)
7 KEBUTUHAN BERUBAH-UBAH
 USER SULIT MENJELASKAN KEBUTUHAN
 MENJADI KEADAAN YANG PALING UMUM UNTUK MEMAKAI PROTOTYPING
27
MODEL SPIRAL
 EVOLUTIONARY PROCESS
 PENGEMBANGAN BERTINGKAT
 MENGGABUNGKAN KEUNGGULAN
 PROTOTYPING
 WATERFALL
 MEMUNGKINKAN DIKEMBANGKAN PERANGKAT LUNAK
 SECARA BERTAHAP (INCREMENTAL)
 DENGAN CEPAT
 TERBAGI ATAS 6 TAHAPAN
 CUSTOMER COMMUNICATION
 PLANNING
 RISK ANALYSIS
 ENGINN\EERING
 CONSTRUCTION & RELEASE
 CUSTOMER EVALUATION
 PENGEMBANG DAN PEMAKAI DAPAT
 MEMAHAMI RESIKO
 BEREAKSI ATAS RESIKO
28
MODEL SPIRAL
PLANNING
RISK ANALYSIS
CUSTOMER
COMMUNICATION
ENGINEERING
CUSTOMER
EVALUATION
CONSTRUCTION
& RELEASE
29
MODEL SPIRAL
PLANNING
RISK ANALYSIS
CUSTOMER
COMMUNICATION
ENGINEERING
PROJECT
ENTRY POINT
CUSTOMER
EVALUATION
CONSTRUCTION
& RELEASE
30
MODEL SPIRAL
 CUSTOMER COMMUNICATION
 PENERAPAN KOMUNIKASI ANTARA USER DENGAN DEVELOPER
CUSTOMER
COMMUNICATION
31
MODEL SPIRAL
 PLANNING
 MENENTUKAN TUJUAN, ALTERNATIF, BATASAN SISTEM
 PENENTUAN KEBUTUHAN AWAL
 DILANJUTKAN DENGAN HASIL EVALUASI USER
PLANNING
32
MODEL SPIRAL
 RISK ANALYSIS
 ANALISA RESIKO
 IDENTIFIKASI RESIKO
 PENANGANNAN RESIKO
RISK ANALYSIS
GO NO GO DECISION
ANALISA RESIKO
BERDASARKAN EVALUASI
USER
ANALISA RESIKO BERDASARKAN
KEBUTUHAN AWAL
33
MODEL SPIRAL
 ENGINEERING
 PENGEMBANGAN PRODUK
 DIMULAI DENGAN PROTOTIPE AWAL
 SAMPAI AKHIRNYA MENJADI PRODUK-JADI
ENGINEERING
PROTOTIPE AWAL
PROTOTIPE TINGKAT
BERIKUTNYA
PRODUK-JADI
34
MODEL SPIRAL
 CONSTRUCTION & RELEASE
 TAHAP KONSTRUKSI, TEST, INSTALL
 & PENYIAPAN USER SUPPORT (DOKUMENTASI)
CONSTRUCTION
& RELEASE
35
MODEL SPIRAL
 CUSTOMER EVALUATION
 PENILAIAN HASIL PENGEMBANGAN PRODUK OLEH USER
 PADA TAHAP PENGEMBANGAN
 MAUPUN TAHAP INSTALASI
CUSTOMER
EVALUATION
36
END-USER DEVELOPMENT
 PENGEMBANGAN PERANGKAT LUNAK OLEH PEMAKAI AKHIR
 DIKERJAKAN TANPA BANTUAN PROFESIONAL
 DIDUKUNG OLEH HADIRNYA PC
 DENGAN BANTUAN 4GL
 FOURTH GENERATION LANGUAGE
 NONPROCEDURAL (LESS PROCEDURAL) LANGUAGE
 JENIS-JENIS
 QUERY LANGUAGE
 REPORT GENERATOR
 GRAPHIC LANGUAGE
 APLICATION GENERATOR
 VERY-HIGH-LEVEL PROGRAMMING LANGUAGE
 APPLICATION SOFTWARE PACKAGE
 MICROCOMPUTER TOOLS
37
END-USER DEVELOPMENT
 MICROSOFT OFFICE
 LOTUS SMART SUITE
 QUERY LANGUAGE
 SQL
 QUERY-BY-EXAMPLE
 REPORT GENERATOR
 RPG 400
 INQUIRE
 GRAPHIC LANGUAGE
 HARVARD GRAPHICS
 SAS GRAPH
 APLICATION GENERATOR
PREPROGRAMMED MODUL
 FOCUS
 DMS
 CSP
 APPLICATION SOFTWARE PACKAGE
 PROGRAM APLIKASI YANG DIPERJUAL-BELIKAN
 VERY-HIGH-LEVEL PROGRAMMING LANGUAGE
 APL
 NOMAD
IS PROFESSIONAL
 MICROCOMPUTER TOOLS
END-USER
 SPEKTRUM
38
END-USER DEVELOPMENT
 KEUNGGULAN END-USER DEVELOPMENT
 LEBIH SESUAI DENGAN KEBUTUHAN USER
 PENINGKATAN KETERLIBATAN USER
 USER LEBIH PUAS
 MEMUDAHKAN PENGENDALIAN PENGEMBANGAN PL
 MEMINIMALKAN KEGAGALAN
 TANTANGAN YANG DIHADAPI
 TIDAK ADANYA REVIEW DARI PIHAK LAIN
 REQUIREMENT BISA TIDAK BENAR
 TIDAK ADANYA STANDAR & KONTROL
 TIAP USER BISA MEMBENTUK SISTEMNYA SENDIRI
 DUPLIKASI DATA
 DATA YANG SAMA ADA PADA TEMPAT YANG BERBEDA
 TERBENTUKNYA SISTEM INFORMASI PRIBADI
 PIHAK LAIN TIDAK MEMAHAMI APA PERILAKU SISTEM
39
REKAYASA KEBUTUHAN
DEFINISI KEBUTUHAN
• BIASANYA DESKRIPSI ABSTRAK
• GOAL/TUJUAN YANG DIINGINKAN
• TIDAK DAPAT DIUJI
SPESIFIKASI KEBUTUHAN
• DESKRIPSI RINCI
• KEMAMPUAN SISTEM
• DAPAT DIUJI
SPESIFIKASI
PERANGKAT LUNAK
• SPESIFIKASI RANCANGAN
• DASAR YG DIPAKAI UNTUK MERANCANG
• UNTUK PEREKAYASA
40
REKAYASA KEBUTUHAN
STUDI
KELAYAKAN
ANALISA
KEBUTUHAN
DEFINISI
KEBUTUHAN
LAPORAN
KELAYAKAN
SPESIFIKASI
LEBUTUHAN
MODEL
SISTEM
DEFINISI
DARI
KEBUTUHAN
SPESIFIKASI
DARI
KEBUTUHAN
DOKUMEN
KEBUTUHAN
41
STUDI KELAYAKAN
 ESTIMASI KEBUTUHAN
 APA SEBENARNYA YANG DIINGINKAN
 KEMUNGKINAN HASIL:
 DAPAT DIPENUHI DENGAN YANG DIMILIKI
 PERANGKAT KERAS
 PERANGKAT LUNAK
 SUMBER DAYA
 HARUS MEMBUAT YANG BARU
 ANALISA BIAYA-EFEKTIF
 BATASAN BIAYA
 BATASAN WAKTU
 SUMBER DAYA
 STUDI KELAYAKAN HARUS DILAKUKAN DENGAN
 MURAH & CEPAT
 JANGAN MENGHABISKAN WAKTU & BIAYA
42
STUDI KELAYAKAN
 HASIL STUDI DIPAKAI UNTUK MENGAMBIL KEPUTUSAN
 KEMUNGKINAN HASIL:
 TERUSKAN
 LAKUKAN ANALISA LEBIH RINCI
 ANALISA KEBUTUHAN
 DEFINISI KEBUTUHAN
 SPESIFIKASI KEBUTUHAN
 HENTIKAN
 TIDAK LAYAK UNTUK DIKEMBANGKAN
 KELAYAKAN
 TEKNIS
 BIAYA
TIDAK BISA
TIDAK MAMPU
TIDAK ADA
TERLALU BESAR
 WAKTU
TIDAK ADA
TIDAK CUKUP
43
ANALISA KEBUTUHAN
 MENCARI KEBUTUHAN MELALUI
 OBSERVASI SISTEM YANG ADA
 DILAKUKAN DENGAN CARA
 DISKUSI DENGAN CALON PEMAKAI
 DISKUSI DENGAN CALON PENGEMBANG
 ANALISA TUGAS & KEGIATAN
 FORMULASI KEBUTUHAN DILAKUKAN DENGAN
 PEMBUATAN MODEL
 DIAGRAM ALIRAN DATA
 DIAGRAM-ER
 SYSTEM FLOWCHART
 STATE TRANSITION DIAGRAM
 OBJECT DIAGRAM
DLL
 PEMBUATAN PROTOTIPE
 PROTOTIPE KERTAS
 PROTOTIPEBERBASIS PC
 PROTOTIPE KERJA
 PROTOTIPE PROGRAM
44
DEFINISI KEBUTUHAN
 DEFINISI TENTANG KEBUTUHAN SISTEM
 MERUPAKAN DESKRIPSI ABSTRAK
 DITULIS DALAM BAHASA SEHARI-HARI
 BERBENTUK NARASI
 URAIAN
 END-USER POINT OF VIEW
 DARI SUDUT PANDANG USER
 APA YANG DIINGINKAN PEMAKAI
 GOAL/SASARAN
 TUJUAN YANG INGIN DICAPAI
 MENERJEMAHKAN KEBUTUHAN KE
DOKUMEN
 BENTUK-BENTUK DOKUMEN YANG DIINGINKAN
 MASUKAN
 KELUARAN
45
SPESIFIKASI KEBUTUHAN
 ADALAH SPESIFIKASI KEMAMPUAN SISTEM
 BERBENTUK DEFINISI RINCI
 UNTUK STAF TEKNIS
 CALON PEMAKAI
 PIHAK YANG AKAN MEMANFAATKAN
 CALON PENGEMBANG
 PIHAK YANG AKAN MEMBUAT
 BERBENTUK DOKUMEN TERSTRUKTUR
 SPESIFIKASI FUNGSIONAL
 RINCIAN TIAP FUNGSI
 BISA DIPAKAI SEBAGAI
 DASAR KONTRAK KERJA
 ANTARA PEMAKAI DENGAN PENGEMBANG
 BASIS UNTUK ACCEPTANCE TESTING
 PENGUJIAN OLEH USER
 SERING PARALEL DENGAN RANCANGAN GLOBAL
46
MODEL SISTEM
 ADALAH:
 JEMBATAN ANTARA ANALISA & PERANCANGAN
 MODEL YANG DIHASILKAN MENJADI BASIS
UNTUK PERANCANGAN
 ABSTRAKSI DARI SISTEM YANG SEDANG DIPELAJARI
 GAMBARAN GRAFIS TENTANG BENTUK SISTEM
 TIDAK BERBENTUK NARASI (KALIMAT-KALIMAT)
 MEMANFAATKAN GAMBAR-GAMBAR
 MEMPERLIHATKAN HAL-HAL YANG PENTING DIPERHATIKAN
 TERGANTUNG PEMODELAN YANG DIPAKAI
 BANYAK JENIS PEMODELAN YANG BISA DIPAKAI
 TIAP MODEL MENJELASKAN DENGAN CARA MASING-MASING
 TIAP MODEL MENGGUNAKAN PENDEKATAN YANG BERBEDA
 TIDAK ADA MODEL YANG IDEAL
 YANG TERBAIK KEMBANGKAN BEBERAPA MODEL
47
MODEL SISTEM
 BEBERAPA DIANTARA MODEL SISTEM:
 DATA-PROCESSING MODEL
 DATA-FLOW DIAGRAM
 MEMPERLIHATKAN FUNGSI / PROSES APA YANG ADA
 BAGAIMANA DATA DIPROSES
 COMPOSITION MODEL
 ENTITY-RELATIONSHIP DIAGRAM
 MEMPERLIHATKAN DATA YANG ADA DI DALAM SISTEM
 HUBUNGAN ANTAR ENTITAS
 CLASSIFICATION MODEL
 OBJECT MODEL / INHERITANCE DIAGRAM
 MEMPERLIHATKAN KESAMAAAN KARAKTERISTIK ENTITAS
 UNTUK PENDEKATAN BERORIENTASI OBYEK
 STIMULUS-RESPONSE MODEL
 STATE TRANSITION DIAGRAM
 REAKSI TERHADAP KEJADIAN INTERNAL & EKSTERNAL
 UNTUK PROSES-PROSES REAL-TIME
48
STRUCTURED A & D
PERMASALAHAN
ENTITY
RELATIONSHIP
ANALYSIS
ANALISA
DATA
ENTITY
RELATIONSHIP
DIAGRAM
LOGICAL
RECORD
STRUCTURE
ANALISA
PROSES
DATA
FLOW
ANALYSIS
DATA FLOW
DIAGRAM
(BERJALAN)
DATA FLOW
DIAGRAM
(USULAN)
RELASI
/ TABEL
STRUCTURED
CHART
NORMALISASI
RELASI
NORMAL
SPESIFIKASI
BASIS DATA
SPESIFIKASI
MODUL /
PSEUDOCODE
49
STRUCTURED A & D
PERMASALAHAN
ENTITY
RELATIONSHIP
ANALYSIS
ANALISA
DATA
ANALISA
PROSES
ENTITY
RELATIONSHIP
DIAGRAM
SALING
MEMPENGARUHI
DATA
FLOW
ANALYSIS
DATA FLOW
DIAGRAM
(BERJALAN)
DATA FLOW
DIAGRAM
(USULAN)
LOGICAL
RECORD
STRUCTURE
RELASI
/ TABEL
MEMBERI
PENGARUH
NORMALISASI
STRUCTURED
CHART
RELASI
NORMAL
SPESIFIKASI
BASIS DATA
SPESIFIKASI
MODUL /
PSEUDOCODE
50
OBJECT MODEL
STRUCTURED ANALYSIS& STRUCTURED DESIGN
DFD BERJALAN
DFD RANCANGAN
STRUCTURED CHART
ER-DIAGRAM
51
OBJECT MODEL
O-O MODEL WITH
O-O MODEL WITH
ATTRIBUTE & RELATIONSHIP
ATTRIBUTE , RELATIONSHIP
& METHOD
MOBIL
CLASS
MEREK
OBJECT
NOMOR RANGKA
ATTRIBUTE
MESIN
MESIN HIDUP
LAMPU MENYALA
METHOD
52
OBJECT MODEL
O-O VERSUS SASD
 SASD
 PERALIHAN MODEL
 DARI ANALISA KE RANCANGAN KE IMPLEMENTASI
 METODOLOGI YANG MATANG (20 TAHUN)
 KRITERIA JELAS & LENGKAP
 CASE TOOL BANYAK
 TEXT BOOK BANYAK
 O-O AD
 SATU MODEL UNTUK SEMUA TAHAPAN
 OBJECT MODEL
 MASIH MUDA (SEDANG BERKEMBANG)
 DUKUNGAN DARI BAHASA PEMROGRAMAN BARU
53
OBJECT MODEL
• OBJECT MODEL
• REPRESENTASI DARI DATA & PROSES
• SEAKAN-AKAN KOMBINASI DFD & ERD
• MEMPERLIHATKAN KLASIFIKASI & PENGELOMPOKAN ENTITY
• NOTASI
CLASS NAME
ATTRIBUTE
SERVICE/OPERATION
54
OBJECT MODEL
• OBJECT MODEL
• PEMODELAN YANG TERUTAMA
• MENGGAMBARKAN ABSTRAKSI DARI OBYEK
• PENGELOMPOKAN BERDASARKAN KESAMAAN ATRIBUT
• MENJELASKAN OPERASI DARI TIAP OBYEK
• JUGA
• HUBUNGAN ANTAR OBYEK
• PENGUMPULAN OBYEK
• OBYEK DIBENTUK DARI KUMPULAN OBYEK-OBYEK
• PEMANFAATAN OPERASI
55
PERANCANGAN PERANGKAT LUNAK
 MERANCANG ADALAH PROSES KREATIF
 KUNCINYA HARUS SERING BERLATIH
 TIGA TAHAP MENGATASI PROBLEMA DALAM PERANCANGAN
BUAT RANCANGAN RINCI
TENTUKAN RANCANGAN GLOBAL
PELAJARI & PAHAMI
PERMASALAHAN
56
PERANCANGAN PERANGKAT LUNAK
 TIGA TAHAP
MENGATASI PROBLEMA DALAM PERANCANGAN(Ljt)
 PELAJARI & PAHAMI PERMASALAHAN
 TANPA PEMAHAMAN TIDAK BERMANFAAT
 PEMAHAMAN BISA SALAH
 PEMAHAMAN YG SALAH MEMBAWA KEARAH YG SALAH
 PEMAHAMAN YANG BENAR
 MEMUDAHKAN PENERIMAAN OLEH USER
 LIHAT DARI BERBAGAI SUDUT PANDANG
 KEBUTUHAN BISA TERLIHAT BERBEDA
 CARA MEMAHAMI KEBUTUHAN
 GUNAKAN BERBAGAI PEMODELAN
57
PERANCANGAN PERANGKAT LUNAK
 TIGA TAHAP
MENGATASI PROBLEMA DALAM PERANCANGAN(Ljt)
 TENTUKAN RANCANGAN GLOBAL
 BUAT GARIS BESAR PEMECAHAN PERMASALAHAN
 RANCANG LEBIH DARI SATU ALTERNATIF
 KEMUDIAN LAKUKAN EVALUASI BERSAMA USER
 PILIHAN SOLUSI TERGANTUNG
 PENGALAMAN & PENGETAHUAN PERANCANG
 MEMPENGARUHI BENTUK & PILIHAN SOLUSI
 KETERSEDIAAN REUSABLE COMPONENT
 KOMPONEN YANG DIADOPSI DARI SISTEM LAIN
 KESEDERHANAAN (SIMPLICITY )
 RANCANGAN HARUS DIUPAYAKAN SEDERHANA
58
PERANCANGAN PERANGKAT LUNAK
 TIGA TAHAP
MENGATASI PROBLEMA DALAM PERANCANGAN (Ljt)
 BUAT RANCANGAN RINCI
 SOLUSI YANG TERPILIH DIRINCI
 DILAKUKAN TAHAP-TAHAP IMPLEMENTASI
 TERDIRI DARI-TAHAP-TAHAP
 PERANCANGAN ANTAR MUKA
 PERANCANGAN KOMPONEN
 PERANCANGAN STRUKTUR DATA
 PERANCANGAN ALGORITMA
 DLL
 RANCANGAN RINCI BISA MEMPERLIHATKAN
 KESALAHAN
 KETIDAK LENGKAPAN
TEMUKAN
&
PERBAIKI
59
TAHAP-TAHAP PERANCANGAN
SPESIFIKASI
KEBUTUHAN
RANCANGAN
ARSITEKTUR
ARSITEKTUR
SISTEM
SPESIFIKASI
ABSTRAK
SPESIFIKASI
PERANGKAT
LUNAK
RANCANGAN
ANTAR-MUKA
SPESIFIKASI
ANTAR-MUKA
RANCANGAN
KOMPONEN
SPESIFIKASI
KOMPONEN
RANCANGAN
STRUKTUR
DATA
SPESIFIKASI
STRUKTUR
DATA
RANCANGAN
ALGORITMA
SPESIFIKASI
ALGORITMA
60
TAHAP-TAHAP PERANCANGAN
 RANCANGAN ARSITEKTUR
 SISTEM AKAN BERISI APA SAJA
 KOMPONEN APA YANG TERDAPAT DI DALAM SISTEM
 PENENTUAN SUB-SISTEM YANG MENDUKUNG
 INTERAKSI SISTEM DENGAN LINGKUNGANNYA
 SISTEM APA SAJA YANG ADA DISEKITARNYA
 APA YANG DIBUTUHKAN DARI SISTEM DISEKITARNYA
 APA YANG DAPAT DIBERIKAN UNTUK SISTEM DISEKITARNYA
 SPESIFIKASI ABSTRAK
 SPESIFIKASI TENTANG PERILAKU SISTEM
 DIBUAT UNTUK TIAP SUB-SISTEM
 SATU UNTUK TIAP SUB-SISTEM
 MENJELASKAN TENTANG:
 KEMAMPUAN SISTEM
 APA YANG DAPAT DILAKUKAN OLEH SISTEM
 APA YANG TIDAK DAPAT DILAKUKAN OLEH SISTEM
 BATASAN SISTEM
 BAGAIMANA SISTEM MELAKUKAN PROSES
61
TAHAP-TAHAP PERANCANGAN
 RANCANGAN ANTAR-MUKA
 PENGHUBUNG ANTARA SISTEM DENGAN DUNIA LUAR
 SISTEM DENGAN SISTEM LAINNYA
 SISTEM DENGAN USER
 SUB-SISTEM SATU DENGAN LAINNYA
 RANCANGAN KOMPONEN
 PROSES DIKELOMPOKKAN
 DITEMPATKAN KE DALAM MODUL-MODUL TERPISAH
 PENENTUAN ANTAR-MUKA ANTAR KOMPONEN
 RANCANGAN STRUKTUR-DATA
 RINCIAN STRUKTUR-DATA YANG DIPAKAI OLEH SISTEM
 PILIHAN STRUKTUR DATA DITENTUKAN
 RANCANGAN ALGORITMA
 RINCIAN ALGORITMA PEMECAHAN MASALAH
 PILIHAN PEMANFAATAN ALGORITMA TERTENTU
62
STRATEGI PERANCANGAN
FUNCTIONAL DESIGN
STRATEGI PERANCANGAN
OBJECT-ORIENTED
DESIGN
63
STRATEGI PERANCANGAN
 RANCANGAN FUNGSIONAL
SISTEM DIRANCANG DENGAN MELIHAT PROSES APA
SAJA YANG ADA DI DALAMNYA
 BERTAHAP DARI HIGH-LEVEL KE DETAIL DESIGN

STRATEGI YANG DIPAKAI STRUCTURE DESIGN
MEMANFAATKAN
DATA-FLOW MODEL
 ENTITY-RELATIONSHIP MODEL
 STRUCTURAL MODEL
 STRUCTURE CHART
 ALTERNATIF STRATEGI
 JACKSON METHOD
 WARNIER-ORR METHOD
64
STRATEGI PERANCANGAN
 RANCANGAN BERORIENTASI OBYEK
SISTEM DIRANCANG SEBAGAI KOLEKSI DARI OBYEK
 IDE DASARNYA ADALAH INFORMATION HIDING
PENYEMBUNYIAN INFORMASI

TIAP OBYEK MEMPUNYAI
 SEJUMLAH ATTRIBUT
 OPERASI BERDASARKAN ATTRIBUT YANG ADA
 OBYEK BISA MEMPUNYAI ATTRIBUT YANG DITURUNKAN
DARI OBYEK LAINNYA
 OBYEK BERKOMUNIKASI DENGAN OBYEK LAINNYA
MELALUI MESSAGE
65
KUALITAS RANCANGAN
TIDAK ADA KESEPAKATAN TENTANG RANCANGAN YANG BAIK
 YANG PENTING RANCANGAN SESUAI SPESIFIKASI
 RANCANGAN YANG BAIK KEMUNGKINAN BERBENTUK
 RANCANGAN EFISIEN
 MENGHASILKAN PROGRAM YANG BEKERJA DENGAN EFISIEN
 RANCANGAN MINIMAL
 MENGHASILKAN PROGRAM SANGAT KOMPAK
 UKURANNYA KECIL
 RANCANGAN YANG MUDAH DIRAWAT
MUDAH DIADAPTASI
DISESUAIKAN DENGAN KEBUTUHAN
DIUBAH/ DITAMBAH/DIKURANGI
 RANCANGAN TERPADU
 PERUBAHAN BERSIFAT LOKAL
 KOHESI TINGGI
 KOPLING RENDAH
66
KOHESI
• KETERKAITAN AKTIFITAS DI DALAM MODUL
• SEMAKIN TINGGI KOHESI SEMAKIN BAIK
• KOHESI ADA 7 MACAM
1 FUNCTIONAL COHESION
2 SEQUENTIAL COHESION
3 COMMUNICATIONAL COHESION
4 PROCEDURAL COHESION
5 TEMPORAL COHESION
6 LOGICAL COHESION
7 COINCIDENTAL COHESION
67
KOHESI
1 FUNCTIONAL COHESION
 HANYA MENGERJAKAN SATU TUGAS
 HANYA MEMPUNYAI SATU TUJUAN
2 INFORMATIONAL (SEQUENTIAL) COHESION
 MODUL MENGERJAKAN URUTAN TUGAS
 DENGAN MEMAKAI STRUKTUR DATA YANG SAMA
FUNCTIONAL
DESIGN
O-O
DESIGN
3 COMMUNICATIONAL COHESION
 MODUL BERISI SEJUMLAH AKTIFITAS
DENGAN MEMAKAI DATA YG SAMA
CONTOH:
UPDATE RECORD IN DATABASE
AND WRITE IT TO AUDIT_FILE
68
KOHESI
4 PROCEDURAL COHESION
 MODUL MENGERJAKAN URUTAN PROSES TERTENTU
 CONTOH:
READ PART# FROM DATABASE
AND UPDATE REPAIR_REC ON MAINT_FILE
5 TEMPORAL COHESION
 MODUL BERISI KELOMPOK KOMPONEN-KOMPONEN MODUL
 TERKELOMPOK KARENA KESAMAAN WAKTU EKSEKUSI
6 LOGICAL COHESION
 MODUL BERISI KOMPONEN YANGMENGERJAKAN TUGAS YANG SAMA
 CONTOH:
SEBUAH MODUL YANG BERISI SEMUA KEGIATAN MENCETAK
7 COINCIDENTAL COHESION
 MODUL MENGERJAKAN BERAGAM TUGAS
 YANG TIDAK SALING TERKAIT
69
KOPLING
• KETERKAITAN MODUL SATU DENGAN LAINNYA
• SEMAKIN RENDAH KOPLING SEMAKIN BAIK
• KELOMPOK KOPLING ADA 3
1 NORMAL COUPLING
A DATA COUPLING
B STAMP COUPLING
C CONTROL COUPLING
2 COMMON COUPLING
3 CONTENT COUPLING
70
KOPLING
1 NORMAL COUPLING
A DATA COUPLING
• KOMUNIKASI DENGAN DATA
B STAMP COUPLING
• KOMUNIKASI DENGAN STRUKTUR DATA
(KESELURUHAN RECORD)
C CONTROL COUPLING
• KOMUNIKASI DENGAN FLAG/SWITCH
2 COMMON COUPLING
• KOMUNIKASI MENGGUNAKAN GLOBAL VARIABLE
3 CONTENT COUPLING
• MODUL MEMPENGARUHI BENTUK STATEMENT
PADA MODUL YANG DIPANGGIL ATAUPUN
SEBALIKNYA
71
PENGUJIAN PERANGKAT LUNAK
• MEMASTIKAN PERANGKAT LUNAK
• SESUAI SPESIFIKASI
• SESUAI KEBUTUHAN PEMAKAI
• SISTEM HARUS DI VERIFIKASI & VALIDASI
• PADA TIAP TAHAP PENGEMBANGAN
• DENGAN DOKUMENTASI DARI TAHAP SEBELUMNYA
?
• VERIFIKASI
 ARE WE BUILDING THE PRODUCT RIGHT
• VALIDASI
 ARE WE BUILDING THE RIGHT PRODUCT
72
PENGUJIAN PERANGKAT LUNAK
• FOKUS PENGUJIAN
• PENCEGAHAN BUG
• PALING TIDAK
• MENUNJUKKAN GEJALA AKIBAT BUG
• INGAT !
MENGETAHUI PROGRAM SALAH
BUKAN MENEMUKAN KESALAHAN
!
• MENGAPA ?
• KESALAHAN BERBEDA, GEJALA BISA SAMA
• SEBUAH KESALAHAN
BISA PUNYA BEBERAPA GEJALA
73
PENGUJIAN PERANGKAT LUNAK
•PROSES PENGUJIAN
UNIT
TESTING
MODULE
TESTING
COMPONENT
TESTING
SUB-SYSTEM
TESTING
SYSTEM
TESTING
INTEGRATION
TESTING
ACCEPTANCE
TESTING
USER
TESTING
74
PENGUJIAN PERANGKAT LUNAK
 COMPONENT TESTING
 PENGUJIAN TERHADAP KOMPONEN SISTEM
 UNIT TESTING
 PENGUJIAN TAHAP AWAL
 PENGUJIAN KOMPONEN SECARA TERPISAH
 UNIT-UNIT TERKECIL DIUJI
 FUNCTION
 PROCEDURE
 SUBPROGRAM
 DLL
 MODULE TESTING
 MODUL MEMADUKAN BEBERAPA KOMPONEN
 MENGUJI INTERAKSI ANTAR UNIT
 MENGUJI PERILAKU MODUL
75
PENGUJIAN PERANGKAT LUNAK
 INTEGRATION TESTING
 PENGUJIAN TERHADAP INTEGRASI ANTAR MODUL
 SUB-SYSTEM TESTING
 PENGUJIAN TERHADAPANTAR MUKA
 MODUL-MODUL YANG SUDAH DIINTEGRASIKAN
 SYSTEM TESTING
 PENGUJIAN TERHADAP PERILAKU SISTEM
 APAKAH SISTEM SESUAI DENGAN SPESIFIKASI
76
PENGUJIAN PERANGKAT LUNAK
 USER TESTING
 PENGUJIAN TAHAP AKHIR
 PENGUJIAN OLEH USER
 ACCEPTANCE TESTING
 DIUJI DENGAN DATA SEBENARNYA
 PENGUJIAN TERHADAP FASILITAS YANG TERSEDIA
 MENILAI KINERJA (PERFORMANCE)
77
PENGUJIAN PERANGKAT LUNAK
•PERENCANAAN PENGUJIAN
REQUIREMENT
SPECIFICATION
SYSTEM
SPECIFICATION
ACCEPTANCE
TEST PLAN
USE
ACCEPTANCE
TEST
DETAILED
DESIGN
SYSTEM
DESIGN
SYSTEM
INTEGRATION
TEST PLAN
SUB-SYSTEM
INTEGRATION
TEST PLAN
SYSTEM
INTEGRATION TEST
MODULE &
UNIT CODE
AND TEST
SUB-SYSTEM
INTEGRATION TEST
78
PENGUJIAN PERANGKAT LUNAK
• STRATEGI PENGUJIAN
• TOP DOWN
• DARI KOMPONEN YANG PALING ABSTRAK
• BOTTOM-UP
• DARI KOMPONEN FUNDAMENTAL
• THREAD
• UNTUK REAL TIME & OBJECT ORIENTED SYSTEM
• STRESS TESTING
• BEBAN MELAMPAUI BATAS
• BACK-TO-BACK
• BILA TERSEDIA >1 VERSI
79
PENGUJIAN PERANGKAT LUNAK
• TEKNIK PENGUJIAN
STATIC
TECHNIQUE
REQUIREMENT
SPECIFICATION
PROTOTYPE
HIGH-LEVEL
DESIGN
FORMAL
SPECIFICATION
DETAILED
DESIGN
PROGRAM
DYNAMIC
TECHNIQUE
80
PENGUJIAN PERANGKAT LUNAK
• PENGUJIAN DINAMIS
• DEFECT TESTING
• MEMPERLIHATKAN ADANYA KESALAHAN
• JENIS:
• BEHAVIORAL TESTING
• FUNCTIONAL TESTING
• BLACK-BOX TESTING
• MENGUJI MELALUI INPUT-OUTPUT
• STRUCTURAL TESTING
• WHITE-BOX TESTING
• GLASS-BOX TESTING
• MENGUJI STRUKTUR PROGRAM
HESTYA PATRIE
ESTYA PATRIE H
STYA PATRIE HE
TYA PATRIE HES
YA PATRIE HEST
• INTERFACE TESTING
• SAAT INTEGRASI
• MENGUJI ANTAR MUKA
81
PENGUJIAN PERANGKAT LUNAK
• WILAYAH PENGUJIAN
TESTING
TEAM
DEVELOPMENT
TEAM
FUNCTONAL
TESTING
INTERFACE
TESTING
STRUCTURAL
TESTING
SYSTEM
SUB-SYSTEM
UNIT AND
CODE
82
SOFTWARE METRICS
 KARAKTERISTIK SEBUAH PROYEK REKAYASA PERANGKAT LUNAK
 PRODUK TIDAK TERUKUR
 TIDAK ADA BAGIAN-BAGIAN PL YANG DAPAT
 DILIHAT
 DIPEGANG
 HANYA DOKUMENTASI YANG DAPAT DIPAKAI
 SEBAGAI UKURAN KEMAJUAN PROYEK
 PROSES TIDAK BAKU
 BANYAK PARADIGMA YANG DAPAT DIPAKAI
 TIDAK ADA JAMIMAN SEBUAH PARADIGMA LEBIH BAIK
 TIAP PROYEK BERBEDA
 KESAMAAN SEBUAH PL SERINGKALI SEMU
 PROYEK YANG SAMA BISA SECARA RINCI BERBEDA
83
SOFTWARE METRICS
 SOFTWARE METRICS
 PENGUKURAN PERANGKAT LUNAK
 PENGUKURAN TENTANG
 PRODUKTIFITAS
 KECEPATAN KERJA
 KERUMITAN
 KUALITAS
 EFISIENSI
 MAINTAINABILITY
 DUA MACAM PENGUKURAN
 PENGUKURAN LANGSUNG
 BANYAKNYA BARIS-BARIS PROGRAM (LOC)
 KECEPATAN PROSES
 BESAR MEMORY YANG DIPAKAI
 PENGUKURAN TIDAK LANGSUNG
 FUNGSIONALITAS
 KUALITAS
 KOMPLEKSITAS
 EFISIENSI
 KEHANDALAN
84
SOFTWARE METRICS
SOFTWARE METRICS
PENGUKURAN PERANGKAT LUNAK
PENGUKURAN LANGSUNG
• BANYAKNYA BARIS
• KECEPATAN PROSES
• BESAR MEMORY
PENGUKURAN TIDAK LANGSUNG
• FUNGSIONALITAS
• KUALITAS
• KOMPLEKSITAS
• EFISIENSI
• KEHANDALAN
85
SOFTWARE METRICS
SOFTWARE METRICS
PENGUKURAN PERANGKAT LUNAK
TUJUAN PENGUKURAN :
 MENGETAHUI KUALITAS PERANGKAT LUNAK
 MENILAI PRODUKTIFITAS PEMBUAT PERANGKAT LUNAK
 MENILAI MANFAAT SEBUAH METODA
 UNTUK DASAR PERKIRAAN
 MEMBANTU PENGAMBILAN KEPUTUSAN
 ALAT BARU
 TAMBAHAN PENDIDIKAN
86
SOFTWARE METRICS
 TUJUAN PENGUKURAN
 MENGETAHUI KUALITAS PERANGKAT LUNAK
 APA YANG DIMAKSUD DENGAN BAIK ATAU JELEK
 MENILAI PRODUKTIFITAS PEMBUATAN PERANGKAT LUNAK
 KECEPATAN PEMBUATAN
 UKURAN PERANGKAT LUNAK
 MENILAI MANFAAT DARI PENERAPAN SEBUAH METODA
 MENCARI PARADIGMA ANDALAN
 BISA MENJADI DASAR UNTUK MELAKUKAN PERKIRAAN
 PEDOMAN DIMASA MENDATANG
 MEMBANTU UNTUK MEMASTIKAN APAKAH DIBUTUHKAN
 PERALATAN BARU
 PELATIHAN TAMBAHAN
87
SOFTWARE METRICS
SOFTWARE METRICS
Technical Metrics
Quality Metrics
Productivity Metrics
Size Oriented Metrics
Function-Oriented Metrics
Human-oriented Metrics
88
SOFTWARE METRICS
 JENIS METRICS
 PRODUCTIVITY METRICS
 MENILAI HASIL REKAYASA PERANGKAT LUNAK
 QUALITY METRICS
 MENILAI SEJAUH MANA PL TELAH SESUAI DENGAN
KEBUTUHAN USER
 TECHNICAL METRICS
 MENILAI KERUMITAN LOGIKA & TINGKAT MODULARITAS
 SIZE-ORIENTED METRICS
 BESAR FISIK SEBUAH PERANGKAT LUNAK
 FUNCTION-ORIENTED METRICS
 MENGUKUR FUNGSIONALITAS & UTILITAS PERANGKAT LUNAK
 HUMAN-ORIENTED METRICS
 MENILAI EFEKTIFITAS METODA / PARADIGMA YG DIPAKAI
89
SOFTWARE METRICS
 SIZE-ORIENTED METRICS
 PENGUKURAN LANGSUNG
 MENGUKUR BESAR-KECILNYA SEBUAH PERANGKAT LUNAK
 DENGAN MENGHITUNG BANYAKNYA BARIS PROGRAM
 LINE OF CODE
(LOC)
 KILO LINE OF CODE (KLOC)
 MENGUKUR PRODUKTIFITAS PENGEMBANG
PRODUKTIFITAS = KLOC / ORANG
 DAPAT DIPAKAI MERANCANG METRICS-METRICS LAIN
KUALITAS = KESALAHAN / KLOC
BIAYA = RUPIAH / LOC
DOKUMENTASI = LEMBAR / KLOC
90
SOFTWARE METRICS
 FUNCTION-ORIENTED METRICS
 PENGUKURAN TIDAK LANGSUNG
 MENGUKUR FUNGSIONALITAS & UTILITAS PERANGKAT LUNAK
 MEMAKAI FUNCTION POINT
A FUNCTION POINT
 MENGHITUNG
 JUMLAH USER INPUT
 SEMUA USER INPUT
 YANG DIBUTUHKAN OLEH TIAP APLIKASI
 JUMLAH USER OUTPUT
 SEMUA KELUARAN
 LAPORAN
 TAMPILAN LAYAR
 PESAN KESALAHAN
 DLL.
 JUMLAH USER ENQUIRY
 MASUKAN ON-LINE YANG MENGAKIBATKAN
KELUARAN ON-LINE
 JUMLAH FILE
 JUMLAH ANTAR MUKA EKSTERNAL
 HUBUNGAN DENGAN SISTEM LAIN
(FILE DI DALAM DISK)
91
SOFTWARE METRICS
 FUNCTION POINT (Albrecht)
FAKTOR KERUMITAN
PARAMETER
INPUT
OUTPUT
INQUIRY
FILE
INTERFACE
JUMLAH
MUDAH RATA-2
X
X
X
X
X
3
4
3
7
5
4
5
4
10
7
TOTAL
RUMIT
TOTAL
6
7
6
15
10
 DIBUAT DARI PENGALAMAN2 YANG BERDASARKAN
UKURAN2 YANG DAPAT DINILAI PADA SEBUAH PL DAN
KOMPLEKSITASNYA
 ORGANISASI HARUS MENGEMBANGKAN POLA UNTUK
MENENTUKAN FAKTOR PEMBERAT
92
SOFTWARE METRICS
 FUNCTION ORIENTED METRICS
B FEATURE POINT
• JUMLAH USER INPUT
• JUMLAH USER OUTPUT
• LAPORAN
• TAMPILAN LAYAR
• PESAN KESALAHAN
• DLL
• JUMLAH USER ENQUIRIES
• JUMLAH FILE
• JUMLAH ANTAR MUKA EKSTERNAL
• DENGAN SISTEM LAIN
• JUMLAH ALGORITMA (YANG RUMIT)
• INVERSE MATRIX
• DECODING BIT
93
SOFTWARE METRICS
FEATURE POINT (Jones)
PARAMETER
INPUT
OUTPUT
INQUIRY
FILE
INTERFACE
ALGORITMA
TOTAL
JUMLAH
X
X
X
X
X
X
PEMBERAT TOTAL
4
5
4
7
7
3
FP (Function Point) has no direct physical meaning, it’s just a number
94
SOFTWARE METRICS
KUALITAS PERANGKAT LUNAK
1 CORRECTNESS
• PERANGKAT LUNAK BEKERJA DENGAN BAIK & BENAR
• CORRECTNESS = KESALAHAN / KLOC
2 MAINTAINABILITY
• MUDAH DIRAWAT
• MTTC (MEAN TIME TO CHANGE) KECIL
3 INTEGRITY
• TAHAN GANGGUAN
• TINGKAT SEKURITI YANG BAIK
4 USABILITY
• MUDAH DIGUNAKAN
95