Presentasi sedang didownload. Silahkan tunggu

Presentasi sedang didownload. Silahkan tunggu

1 DEFINISI  REKAYASA PERANGKAT LUNAK SANGAT BERKAITAN DENGAN PENGEMBANGAN PERANGKAT SISTEM OLEH TIM (KELOMPOK)  REKAYASA PERANGKAT LUNAK MEMANFAATKAN.

Presentasi serupa


Presentasi berjudul: "1 DEFINISI  REKAYASA PERANGKAT LUNAK SANGAT BERKAITAN DENGAN PENGEMBANGAN PERANGKAT SISTEM OLEH TIM (KELOMPOK)  REKAYASA PERANGKAT LUNAK MEMANFAATKAN."— Transcript presentasi:

1 1 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

2 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  AWAM DENGAN TEKNOLOGI & METODOLOGI

3 3 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

4 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  DAN JANGKA WAKTU YANG TERTENTU

5 5 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

6 6 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

7 7 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) SUBROUTINE OBJECT/ CLASS BERISI ALGORITMA & STRUKTUR DATA BERISI ALGORITMA

8 8 LATAR BELAKANG  REKAYASA PERANGKAT LUNAK MENGHASILKAN PRODUK BERBENTUK  PERANGKAT LUNAK LENGKAP DENGAN DOKUMENTASINYA  DUA MACAM PRODUK PERANGKAT LUNAK GENERIKSPESIFIK PRODUK YANG DIKEMBANGKAN KHUSUS UNTUK SEBUAH PERUSAHAAN PRODUK YANG DIKEMBANGKAN UNTUK DIJUAL KEPADA PUBLIK

9 9 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 MILIDETIK  BUSINESS SOFTWARE  PERANGKAT LUNAK APLIKASI  PENGGAJIAN  PENJUALAN  PERSEDIAAN BARANG  DLL  KADANG TERPADU MENJADI SATUSIM

10 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  DLL

11 11 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

12 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  DIANTARANYA PROGRAMMER

13 13 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

14 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  DAMPAK SANGAT BERGANTUNG PADA TAHAP MANA PERUBAHAN TERJADI

15 15 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

16 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  PENYESUAIAN MENGIKUTI PERUBAHAN KEBUTUHAN

17 17 WATERFALL MODEL DEFINISI KEBUTUHAN SISTEM RANCANG SISTEM IMPLEMENTASI & UNIT TESTING INTEGRASI & SYSTEM TESTING OPERASI & PERAWATAN

18 18 WATERFALL MODEL  ANALISA & DEFINISI KEBUTUHAN SISTEM  DIURAIKAN TENTANG  KEMAMPUAN  BATASANSISTEM  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  PERBAIKAN, PERUBAHAN & PENGEMBANGAN

19 19 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

20 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  APA YANG HARUS DILAKUKAN

21 21  MACAM EVOLUTIONARY THROWAWAY DIMULAI DARI MODEL DIKEMBANGKAN AKHIRNYA DIMANFAATKAN HANYA DIBUAT SEBAGAI MODEL UNTUK MENCARI BENTUK YANG DIINGINKAN (CETAK BIRU) PROTOTYPING

22 22  DISEBUT EVOLUTIONARY PROTOTYPE GUNAKAN PROTOTIPE BUAT PROTOTIPE TENTUKAN KEBUTUHAN EVALUASI TIDAK SESUAI SESUAI PROTOTYPING

23 23 PROTOTYPING GUNAKAN SISTEM UJI SISTEM PROGRAM SISTEM EVALUASI TIDAK SESUAI TIDAK SESUAI BUAT PROTOTIPE TENTUKAN KEBUTUHAN EVALUASI SESUAI THROWAWAY PROTOTYPE

24 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 PROTOTYPING

25 25 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

26 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  LEBIH MEMENTINGKAN KEBERHASILAN

27 27 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

28 28  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 MODEL SPIRAL

29 29 MODEL SPIRAL PLANNING RISK ANALYSIS ENGINEERING CUSTOMER EVALUATION CONSTRUCTION & RELEASE CUSTOMER COMMUNICATION

30 30 MODEL SPIRAL PLANNING RISK ANALYSIS ENGINEERING CUSTOMER EVALUATION CONSTRUCTION & RELEASE CUSTOMER COMMUNICATION PROJECT ENTRY POINT

31 31  CUSTOMER COMMUNICATION  PENERAPAN KOMUNIKASI ANTARA USER DENGAN DEVELOPER MODEL SPIRAL CUSTOMER COMMUNICATION

32 32  PLANNING  MENENTUKAN TUJUAN, ALTERNATIF, BATASAN SISTEM  PENENTUAN KEBUTUHAN AWAL  DILANJUTKAN DENGAN HASIL EVALUASI USER MODEL SPIRAL PLANNING

33 33  RISK ANALYSIS  ANALISA RESIKO  IDENTIFIKASI RESIKO  PENANGANNAN RESIKO MODEL SPIRAL RISK ANALYSIS GO NO GO DECISION ANALISA RESIKO BERDASARKAN KEBUTUHAN AWAL ANALISA RESIKO BERDASARKAN EVALUASI USER

34 34  ENGINEERING  PENGEMBANGAN PRODUK  DIMULAI DENGAN PROTOTIPE AWAL  SAMPAI AKHIRNYA MENJADI PRODUK-JADI MODEL SPIRAL ENGINEERING PRODUK-JADI PROTOTIPE AWAL PROTOTIPE TINGKAT BERIKUTNYA

35 35  CONSTRUCTION & RELEASE  TAHAP KONSTRUKSI, TEST, INSTALL  & PENYIAPAN USER SUPPORT (DOKUMENTASI) MODEL SPIRAL CONSTRUCTION & RELEASE

36 36 CUSTOMER EVALUATION  CUSTOMER EVALUATION  PENILAIAN HASIL PENGEMBANGAN PRODUK OLEH USER  PADA TAHAP PENGEMBANGAN  MAUPUN TAHAP INSTALASI MODEL SPIRAL

37 37 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

38 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 END-USER IS PROFESSIONAL

39 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  PIHAK LAIN TIDAK MEMAHAMI APA PERILAKU SISTEM END-USER DEVELOPMENT

40 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 • UNTUK PEREKAYASA

41 41 REKAYASA KEBUTUHAN ANALISA KEBUTUHAN DEFINISI KEBUTUHAN MODEL SISTEM DEFINISI DARI KEBUTUHAN DOKUMEN KEBUTUHAN STUDI KELAYAKAN LAPORAN KELAYAKAN SPESIFIKASI LEBUTUHAN SPESIFIKASI DARI KEBUTUHAN

42 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  JANGAN MENGHABISKAN WAKTU & BIAYA

43 43 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 TIDAK BISA TIDAK MAMPU  BIAYA TIDAK ADA TERLALU BESAR  WAKTU TIDAK ADA TIDAK CUKUP

44 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  PROTOTIPE PROGRAM

45 45 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

46 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  SERING PARALEL DENGAN RANCANGAN GLOBAL

47 47 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

48 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  UNTUK PROSES-PROSES REAL-TIME

49 49 STRUCTURED A & D PERMASALAHAN ANALISA PROSES ANALISA 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 / PSEUDOCODE NORMALISASI

50 50 STRUCTURED A & D PERMASALAHAN ANALISA PROSES ANALISA 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 / PSEUDOCODE NORMALISASI SALING MEMPENGARUHI MEMBERI PENGARUH

51 51 OBJECT MODEL STRUCTURED ANALYSIS& STRUCTURED DESIGN DFD BERJALAN DFD RANCANGAN STRUCTURED CHART ER-DIAGRAM

52 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 NOMOR RANGKA MESIN

53 53 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

54 54 OBJECT MODEL • OBJECT MODEL • REPRESENTASI DARI DATA & PROSES • SEAKAN-AKAN KOMBINASI DFD & ERD • MEMPERLIHATKAN KLASIFIKASI & PENGELOMPOKAN ENTITY • NOTASI CLASS NAME ATTRIBUTE SERVICE/OPERATION

55 55 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

56 56 PERANCANGAN PERANGKAT LUNAK  MERANCANG ADALAH PROSES KREATIF  KUNCINYA HARUS SERING BERLATIH  TIGA TAHAP MENGATASI PROBLEMA DALAM PERANCANGAN PELAJARI & PAHAMI PERMASALAHAN TENTUKAN RANCANGAN GLOBAL BUAT RANCANGAN RINCI

57 57 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

58 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 )  RANCANGAN HARUS DIUPAYAKAN SEDERHANA

59 59 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

60 60 TAHAP-TAHAP PERANCANGAN SPESIFIKASI KEBUTUHAN RANCANGAN ARSITEKTUR SPESIFIKASI ABSTRAK RANCANGAN ANTAR-MUKA RANCANGAN KOMPONEN RANCANGAN STRUKTUR DATA RANCANGAN ALGORITMA ARSITEKTUR SISTEM SPESIFIKASI PERANGKAT LUNAK SPESIFIKASI ANTAR-MUKA SPESIFIKASI KOMPONEN SPESIFIKASI STRUKTUR DATA SPESIFIKASI ALGORITMA

61 61 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

62 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  PILIHAN PEMANFAATAN ALGORITMA TERTENTU

63 63 STRATEGI PERANCANGAN FUNCTIONAL DESIGN OBJECT-ORIENTED DESIGN

64 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 STRATEGI PERANCANGAN

65 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  MELALUI MESSAGE STRATEGI PERANCANGAN

66 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  KOHESI TINGGI  KOPLING RENDAH

67 67 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

68 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 O-O DESIGN

69 69 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

70 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 3 CONTENT COUPLING

71 71 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

72 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 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 ! PENGUJIAN PERANGKAT LUNAK

74 74 PENGUJIAN PERANGKAT LUNAK • PROSES PENGUJIAN UNIT TESTING MODULE TESTING SUB-SYSTEM TESTING SYSTEM TESTING ACCEPTANCE TESTING COMPONENT TESTING INTEGRATION TESTING USER TESTING

75 75 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

76 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  APAKAH SISTEM SESUAI DENGAN SPESIFIKASI

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

78 78 PENGUJIAN PERANGKAT LUNAK • PERENCANAAN PENGUJIAN REQUIREMENT SPECIFICATION SYSTEM SPECIFICATION SYSTEM DESIGN DETAILED DESIGN MODULE & UNIT CODE AND TEST SUB-SYSTEM INTEGRATION TEST SYSTEM INTEGRATION TEST ACCEPTANCE TEST USE ACCEPTANCE TEST PLAN SYSTEM INTEGRATION TEST PLAN SUB-SYSTEM INTEGRATION TEST PLAN

79 79 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

80 80 PENGUJIAN PERANGKAT LUNAK • TEKNIK PENGUJIAN STATIC TECHNIQUE REQUIREMENT SPECIFICATION HIGH-LEVEL DESIGN FORMAL SPECIFICATION DETAILED DESIGN PROGRAM PROTOTYPE DYNAMIC TECHNIQUE

81 81 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 • INTERFACE TESTING • SAAT INTEGRASI • MENGUJI ANTAR MUKA HESTYA PATRIE ESTYA PATRIE H STYA PATRIE HE TYA PATRIE HES YA PATRIE HEST

82 82 PENGUJIAN PERANGKAT LUNAK • WILAYAH PENGUJIAN FUNCTONAL TESTING INTERFACE TESTING STRUCTURAL TESTING UNIT AND CODE SYSTEMSUB-SYSTEM TESTING TEAM DEVELOPMENT TEAM

83 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  PROYEK YANG SAMA BISA SECARA RINCI BERBEDA SOFTWARE METRICS

84 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 SOFTWARE METRICS

85 85 SOFTWARE METRICS PENGUKURAN PERANGKAT LUNAK PENGUKURAN LANGSUNG • BANYAKNYA BARIS • KECEPATAN PROSES • BESAR MEMORY PENGUKURAN TIDAK LANGSUNG • FUNGSIONALITAS • KUALITAS • KOMPLEKSITAS • EFISIENSI • KEHANDALAN

86 86 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

87 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  PELATIHAN TAMBAHAN SOFTWARE METRICS

88 88 SOFTWARE METRICS Human-oriented Metrics Productivity Metrics Quality Metrics Technical Metrics Size Oriented Metrics Function-Oriented Metrics

89 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  MENILAI EFEKTIFITAS METODA / PARADIGMA YG DIPAKAI SOFTWARE METRICS

90 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 SOFTWARE METRICS

91 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  HUBUNGAN DENGAN SISTEM LAIN (FILE DI DALAM DISK) SOFTWARE METRICS

92 92  FUNCTION POINT (Albrecht) FAKTOR KERUMITAN PARAMETER JUMLAHMUDAHRATA-2RUMIT INPUTX OUTPUTX INQUIRYX FILEX INTERFACEX 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 TOTAL

93 93  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

94 94 SOFTWARE METRICS FEATURE POINT (Jones) PARAMETER JUMLAH PEMBERAT INPUTX4 OUTPUTX5 INQUIRYX4 FILEX7 INTERFACEX7 ALGORITMAX3 TOTAL FP (Function Point) has no direct physical meaning, it’s just a number

95 95 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


Download ppt "1 DEFINISI  REKAYASA PERANGKAT LUNAK SANGAT BERKAITAN DENGAN PENGEMBANGAN PERANGKAT SISTEM OLEH TIM (KELOMPOK)  REKAYASA PERANGKAT LUNAK MEMANFAATKAN."

Presentasi serupa


Iklan oleh Google