e-Books |

1

 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

2

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

3

 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

4

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

5

 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

6

LATAR BELAKANG

 PRODUK PERANGKAT LUNAK DIKEMBANGKAN DARI SERANGKAIAN PERUBAHAN

 DARI USER REQUIREMENT MENJADI KODE-EKSEKUSI UNTUK MESIN

KEBUTUHAN USER

BENTUK RANCANGAN

BAHASA KOMPUTER

7

 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)

SUBROUTINE

OBJECT/ CLASS

BERISI

8

LATAR BELAKANG

 REKAYASA PERANGKAT LUNAK MENGHASILKAN PRODUK BERBENTUK

 PERANGKAT LUNAK LENGKAP DENGAN DOKUMENTASINYA

 DUA MACAM PRODUK PERANGKAT LUNAK

GENERIK

SPESIFIK

PRODUK YANG DIKEMBANGKAN

KHUSUS UNTUK SEBUAH PERUSAHAAN PRODUK YANG DIKEMBANGKAN

9

 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 MILIDETIK

 BUSINESS SOFTWARE

 PERANGKAT LUNAK APLIKASI

 PENGGAJIAN

 PENJUALAN

 PERSEDIAAN BARANG

 DLL

10

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

11

 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

12

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

13

 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

14

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

15

 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

16

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

PENGEMBANGAN

SPESIFIKASI

VALIDASI

EVOLUSI



TENTANG KEMAMPUAN PERANGKAT LUNAK



BERISI BATASAN OPERASIONAL



TAHAP MENGEMBANGKAN SESUAI SPESIFIKASI



TAHAP PENGUJIAN AGAR SESUAI SPESIFIKASI

17

DEFINISI

KEBUTUHAN SISTEM

RANCANG SISTEM

IMPLEMENTASI &

UNIT TESTING

INTEGRASI &

SYSTEM TESTING

OPERASI &

18

WATERFALL MODEL



ANALISA & DEFINISI KEBUTUHAN SISTEM



DIURAIKAN TENTANG



KEMAMPUAN



BATASAN SISTEM



TUJUAN



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

19



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

20

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

21



MACAM

EVOLUTIONARY

THROWAWAY

DIMULAI DARI MODEL DIKEMBANGKAN

AKHIRNYA DIMANFAATKAN

22



DISEBUT_EVOLUTIONARY

PROTOTYPE

GUNAKAN PROTOTIPE

BUAT PROTOTIPE TENTUKAN KEBUTUHAN

EVALUASI TIDAK SESUAI

23

GUNAKAN SISTEM

UJI SISTEM PROGRAM

SISTEM

EVALUASI TIDAK

SESUAI

SESUAI TIDAK

SESUAI

BUAT PROTOTIPE TENTUKAN KEBUTUHAN

EVALUASI SESUAI THROWAWAY

24



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

25



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

26

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

27



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

28



EVOLUTIONARY PROCESS



PENGEMBANGAN BERTINGKAT



MENGGABUNGKAN KEUNGGULAN



PROTOTYPING



WATERFALL



MEMUNGKINKAN DIKEMBANGKAN PERANGKAT LUNAK



SECARA BERTAHAP (INCREMENTAL)



DENGAN CEPAT



TERBAGI ATAS 6 TAHAPAN

1

CUSTOMER COMMUNICATION

2

PLANNING

3

RISK ANALYSIS

4

ENGINN\EERING

5

CONSTRUCTION & RELEASE

6

CUSTOMER EVALUATION



PENGEMBANG DAN PEMAKAI DAPAT



MEMAHAMI RESIKO



BEREAKSI ATAS RESIKO

29

PLANNING

RISK ANALYSIS

ENGINEERING

CUSTOMER

EVALUATION _CONSTRUCTION

& RELEASE CUSTOMER

30

MODEL SPIRAL

PLANNING

RISK ANALYSIS

ENGINEERING

CUSTOMER

EVALUATION _CONSTRUCTION

& RELEASE CUSTOMER

COMMUNICATION

31



CUSTOMER COMMUNICATION



PENERAPAN KOMUNIKASI ANTARA USER DENGAN DEVELOPER

CUSTOMER

32



PLANNING



MENENTUKAN TUJUAN, ALTERNATIF, BATASAN SISTEM



PENENTUAN KEBUTUHAN AWAL



DILANJUTKAN DENGAN HASIL EVALUASI USER

MODEL SPIRAL

33



RISK ANALYSIS



ANALISA RESIKO



IDENTIFIKASI RESIKO



PENANGANNAN RESIKO

RISK ANALYSIS

GO NO GO DECISION

ANALISA RESIKO BERDASARKAN KEBUTUHAN AWAL

ANALISA RESIKO

34



ENGINEERING



PENGEMBANGAN PRODUK



DIMULAI DENGAN PROTOTIPE AWAL



SAMPAI AKHIRNYA MENJADI PRODUK-JADI

MODEL SPIRAL

ENGINEERING

PRODUK-JADI PROTOTIPE AWAL

35



CONSTRUCTION & RELEASE



TAHAP KONSTRUKSI, TEST, INSTALL



& PENYIAPAN USER SUPPORT (DOKUMENTASI)

36

CUSTOMER EVALUATION



CUSTOMER EVALUATION



PENILAIAN HASIL PENGEMBANGAN PRODUK OLEH USER



PADA TAHAP PENGEMBANGAN



MAUPUN TAHAP INSTALASI

37



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

1

QUERY LANGUAGE

2

REPORT GENERATOR

3

GRAPHIC LANGUAGE

4

APLICATION GENERATOR

5

VERY-HIGH-LEVEL PROGRAMMING LANGUAGE

6

APPLICATION SOFTWARE PACKAGE

38

END-USER DEVELOPMENT



SPEKTRUM



MICROCOMPUTER TOOLS

 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

39



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

40

REKAYASA KEBUTUHAN

SPESIFIKASI KEBUTUHAN

SPESIFIKASI PERANGKAT LUNAK

DEFINISI KEBUTUHAN

•

•

BIASANYA DESKRIPSI ABSTRAK _{GOAL/TUJUAN YANG DIINGINKAN}

•

TIDAK DAPAT DIUJI

•

DESKRIPSI RINCI

•

KEMAMPUAN SISTEM

•

DAPAT DIUJI

•

SPESIFIKASI RANCANGAN

•

DASAR YG DIPAKAI UNTUK MERANCANG

41

ANALISA

KEBUTUHAN

DEFINISI KEBUTUHAN

MODEL SISTEM

DEFINISI DARI KEBUTUHAN

DOKUMEN KEBUTUHAN STUDI

KELAYAKAN

LAPORAN KELAYAKAN

SPESIFIKASI LEBUTUHAN

42

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

43



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

TIDAK BISA TIDAK MAMPU



BIAYA

TIDAK ADA

TERLALU BESAR



WAKTU

44

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

45



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

46

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

47



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

48

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

49

ANALISA PROSES ANALISA DATA DATA FLOW ANALYSIS ENTITY RELATIONSHIP ANALYSIS ENTITY RELATIONSHIP DIAGRAM DATA FLOW DIAGRAM (BERJALAN) LOGICAL RECORD STRUCTURE RELASI / TABEL RELASI NORMAL SPESIFIKASI BASIS DATA DATA FLOW DIAGRAM (USULAN) STRUCTURED CHART SPESIFIKASI MODUL /

50

STRUCTURED A & D

PERMASALAHAN ANALISA PROSES ANALISA DATA DATA FLOW ANALYSIS ENTITY RELATIONSHIP ANALYSIS ENTITY RELATIONSHIP DIAGRAM DATA FLOW DIAGRAM (BERJALAN) LOGICAL RECORD STRUCTURE RELASI / TABEL RELASI NORMAL SPESIFIKASI BASIS DATA DATA FLOW DIAGRAM (USULAN) STRUCTURED CHART SPESIFIKASI MODUL /

51

STRUCTURED ANALYSIS& STRUCTURED DESIGN

DFD BERJALAN DFD RANCANGAN STRUCTURED CHART

52

OBJECT MODEL

MOBIL

MESIN HIDUP LAMPU MENYALA

OBJECT

O-O MODEL WITH

ATTRIBUTE & RELATIONSHIP

O-O MODEL WITH

ATTRIBUTE , RELATIONSHIP & METHOD

CLASS

ATTRIBUTE

METHOD

MEREK

53

 _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)}

54

OBJECT MODEL

•

OBJECT MODEL

•

REPRESENTASI DARI DATA & PROSES

•

SEAKAN-AKAN KOMBINASI DFD & ERD

•

MEMPERLIHATKAN KLASIFIKASI & PENGELOMPOKAN ENTITY

•

NOTASI

CLASS NAME

ATTRIBUTE

55

•

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

56

PERANCANGAN PERANGKAT LUNAK



MERANCANG ADALAH PROSES KREATIF



KUNCINYA HARUS SERING BERLATIH



TIGA TAHAP MENGATASI PROBLEMA DALAM PERANCANGAN

PELAJARI & PAHAMI PERMASALAHAN

57



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

58

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 )

59



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

61

 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

62

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

63

STRATEGI PERANCANGAN

FUNCTIONAL DESIGN

64



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

65



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

66

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

67

•

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

68

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}

3 COMMUNICATIONAL COHESION

 MODUL BERISI SEJUMLAH AKTIFITAS

DENGAN MEMAKAI DATA YG SAMA

_CONTOH:

UPDATE RECORD IN DATABASE AND WRITE IT TO AUDIT_FILE

FUNCTIONAL DESIGN

69

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

70

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

71

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

72

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

?

73

•

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

74

PENGUJIAN PERANGKAT LUNAK

•

PROSES PENGUJIAN

UNIT TESTING

MODULE TESTING

SUB-SYSTEM TESTING

SYSTEM TESTING

ACCEPTANCE TESTING

COMPONENT TESTING

INTEGRATION

75



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

76

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

77



USER TESTING



PENGUJIAN TAHAP AKHIR



PENGUJIAN OLEH USER



ACCEPTANCE TESTING



DIUJI DENGAN DATA SEBENARNYA



PENGUJIAN TERHADAP FASILITAS YANG TERSEDIA

78

PENGUJIAN PERANGKAT LUNAK

•

PERENCANAAN PENGUJIAN

79

•

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

80

PENGUJIAN PERANGKAT LUNAK

•

TEKNIK PENGUJIAN

STATIC TECHNIQUE

REQUIREMENT SPECIFICATION

HIGH-LEVEL DESIGN

FORMAL SPECIFICATION

DETAILED

DESIGN PROGRAM

PROTOTYPE _DYNAMIC

81

•

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

•

INTERFACE TESTING

•

SAAT INTEGRASI

•

MENGUJI ANTAR MUKA

82

PENGUJIAN PERANGKAT LUNAK

•

WILAYAH PENGUJIAN

FUNCTONAL TESTING

INTERFACE TESTING

STRUCTURAL TESTING

UNIT AND CODE

SYSTEM SUB-SYSTEM

TESTING

83



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}

84



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

85

SOFTWARE METRICS

PENGUKURAN PERANGKAT LUNAK

PENGUKURAN LANGSUNG

•

BANYAKNYA BARIS

•

KECEPATAN PROSES

•

BESAR MEMORY

PENGUKURAN TIDAK LANGSUNG

•

FUNGSIONALITAS

•

KUALITAS

•

KOMPLEKSITAS

•

EFISIENSI

86

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}

87



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}

88

SOFTWARE METRICS

SOFTWARE METRICS

Human-oriented Metrics Productivity Metrics

Quality Metrics

Technical Metrics

Size Oriented Metrics

89



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

90



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

91



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

92



FUNCTION POINT (Albrecht)

FAKTOR KERUMITAN

PARAMETER JUMLAH MUDAH RATA-2 RUMIT

INPUT X 3 4 6

OUTPUT X 4 5 7

INQUIRY X 3 4 6

FILE X 7 10 15

INTERFACE X 5 7 10 TOTAL



DIBUAT DARI PENGALAMAN2 YANG BERDASARKAN UKURAN2 YANG DAPAT DINILAI PADA SEBUAH PL DAN KOMPLEKSITASNYA



ORGANISASI HARUS MENGEMBANGKAN POLA UNTUK MENENTUKAN FAKTOR PEMBERAT

SOFTWARE METRICS

93



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

94

SOFTWARE METRICS

FEATURE POINT (Jones)

PARAMETER JUMLAH PEMBERAT

INPUT X 4

OUTPUT X 5

INQUIRY X 4

FILE X 7

INTERFACE X 7

ALGORITMA X 3

TOTAL

TOTAL

95

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