Perancangan Sistem Informasi

Perancangan Sistem Informasi Perancangan Perangkat Lunak

Avinanta Tarigan

Gunadarma University

1

Avinanta Tarigan

Perancangan Sistem Informasi

Outline

2

1

Aspek-aspek Dalam R/P-PL Rekayasa Perangkat Lunak Problema

2

Proses Pengembangan PL Definisi Model Proses Pengembangan PL

3

Pengujian Perangkat Lunak Strategi Pengujian Secara Umum Pengujian PL Berarsitektur Konvensional Pengujian Dalam Konteks PBO Pengujian Sistem

Avinanta Tarigan


Pustaka I Sommerville, Ian, “Software Engineering ”, Addison-Wesley, 1982 Pressman, Roger S, “Software Engineering: A Practitioner’s Approach”, Boston, Mass: McGraw-Hill, 2005 Parnas, David, “Software Engineering Programmes are not Computer Science Programmes”, Annals of Software Engineering, 1998

3

I

Guide to the Software Engineering Body of Knowledge (http://www.swebok.org)

I

Other S.E. Course Related Sites (Wikipedia, MIT, Software Engineering Institute Carnegie Mellon, Ilmukomputer.com, etc)

Avinanta Tarigan


Aspek-aspek Dalam R/P-PL

Rekayasa Perangkat Lunak

Outline

4

1


2


3


Avinanta Tarigan




Software / Perangkat Lunak

Program Komputer, Mekanikal yang dapat dengan mudah dibentuk dan dirubah Produk Perangkat Lunak: Generik : untuk pengguna umum pengguna harus mengikuti apa yang telah dibuat oleh programmer

Bespoke / Tailor-made : dibuat khusus untuk sekelompok pengguna developer mengikuti requirement dari pengguna

5

Avinanta Tarigan




Software / Perangkat Lunak

Program Komputer, Mekanikal yang dapat dengan mudah dibentuk dan dirubah Produk Perangkat Lunak: Generik : untuk pengguna umum pengguna harus mengikuti apa yang telah dibuat oleh programmer

Bespoke / Tailor-made : dibuat khusus untuk sekelompok pengguna developer mengikuti requirement dari pengguna

5

Avinanta Tarigan




Software Engineering I Application of systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software 1968 - NATO Software Engineering Conference, Garmisch, Deutschland. Term was popularized by F.L. Bauer Pioneers: C.A.R. Hoare David Parnas Barry Boehm & Fred Brooks

S.E. is a form of engineering but not just set of good programmers (David Parnas) not engineering but that it should be (Steve McConnell) is an art and a science (Donald Knuth) 6

Avinanta Tarigan




Software Engineering II

Engineers belajar science + metoda untuk mengaplikasikannya Membutuhkan pengetahuan: computer engineering & science, managemen, matematik, manajemen proyek, management kualitas, software ergonomics, system engineering Peneliti (scientist) fokus pada satu subyek dan mendalaminya, tetapi engineer harus memilik pengetahuan yang cukup luas dan melebar

7

Avinanta Tarigan



Problema

Outline

8

1


2


3


Avinanta Tarigan



Problema

Mengapa Kita Harus Belajar PPL

http://blog.amber.org/category/programming/ 9

Avinanta Tarigan



Problema

Karakteristik Software Yang Bagus

Maintainability PL harus dapat dengan mudah dirubah sesuai dengan perubahan kebutuhan pengguna Dependability PL harus dapat dipercaya (trustworthy) sehingga pengguna dapat menggantungkan sepenuhnya proses bisnis mereka Efficiency PL harus efisien dan tidak memakai resources yang tinggi Usability PL harus dapat “digunakan” (usable) oleh penggunanya dalam memenuhi kebutuhan mereka

10

Avinanta Tarigan


Proses Pengembangan PL

Definisi

Outline

11

1


2


3


Avinanta Tarigan



Definisi

Proses Pengembangan PL Himpunan dari aktifitas yang bertujuan untuk mengembangkan PL atau evolusi dari PL Secara generik: 1

2

3

4

12

Spesifikasi Mendifinisikan bagaimana sistem harus bekerja, ruang lingkup, dan hambatan2nya Pengembangan Fase produksi: programming, dokumentasi, cek error, etc Validasi dan verifikasi Memvalidasi bahwa PL dapat memenuhi kebutuhan pengguna (requirement) Evolusi Merubah PL sesuai dengan perubahan kebutuhan pengguna

Avinanta Tarigan



Definisi

Model Proses Pengembangan PL

Simplifikasi proses pengembangan PL dari perspektiv yang spesifik Perspektiv: Workflow - aliran aktivitas Data-Flow based - aliran informasi Role/Action based - peran-peran pengembang

Beberapa model proses PL Waterfall model Evolutionary Formal transformation Integration from reusable components Agile and eXtreme Software Development

13

Avinanta Tarigan




Outline

14

1


2


3


Avinanta Tarigan




The Waterfall Model The Spirit

15

Avinanta Tarigan




The Waterfall Model As is

16

Avinanta Tarigan




The Waterfall Model Problem Dari Waterfall Model

Sangat sulit untuk mengakomodasi perubahan dalam proses Tidak fleksibel dalam pemisahan proyek dalam beberapa langkah pengembangan Tidak mudah untuk merespon perubahan Dapat digunakan apabila kebutuhan pengguna sudah benar2 dimengerti, dikuasai, diresapi dan tidak akan berubah selama pengembangan

17

Avinanta Tarigan




Evolutionary Development Versioning dan Prototyping

18

Avinanta Tarigan




Evolutionary Development Problema dan Pengejawantahannya

Problem: Visibilitas proses tidak jelas terlihat Sistem kadang2 tidak terstruktur Membutuhkan skill khusus (misalnya, bahasa untuk rapid prototyping)

Dapat digunakan dalam: sistem interaktif yang kecil atau menengah mengembangkan bagian dari sistem yang besar (misalnya, user interface) sistem yang life-cyclenya pendek

19

Avinanta Tarigan




Formal System Development Kebutuhan user dispesifikasikan dalam bentuk matematik Bentuk matematik tsb ditransformasikan dalam abstraksi-abstraksi spesifikasi sampai pada program yang dapat dijalankan Requirement Definiiton → Formal Specification → Formal Transformation → Executable Program → Integration & System Testing Transformasi tsb “correctness-preserving”, dapat dengan mudah membuktikan bahwa program akhir sesuai dengan spesifikasi awal Pendekatan “Cleanroom” 20

Avinanta Tarigan




Formal System Development Penggunaannya

investasi awal sangat tinggi bias dalam penyusunan kebutuhan dapat diperkecil karena analisis detail sangat diperlukan dan mandatory ketidaklengkapan dan ketidakkonsistenan dapat diidentifikasi dan dibetulkan penghematan dalam proyek yang biasanya disebabkan oleh problem dalam pendefinisian kebutuhan

21

Avinanta Tarigan




Formal System Development Contoh Spesifikasinya Dalam TLA+

22

Avinanta Tarigan




Formal System Development Formal Transformation and Proofs

P1 ∧ P2 ∧ P3 ∧ P4 ≡ TRUE

23

Avinanta Tarigan




Formal System Development Problems and Applicability

Problema Dibutuhkan kepala yang pintar dan terlatih Tidak mudah (tidak mungkin) untuk memformalkan semua aspek dalam sistem

Aplikasi Critical systems : safety dan security

24

Avinanta Tarigan




Component-Reuse Oriented Development Definisi

Berdasarkan penggunaan kembali komponen-komponen PL dengan metoda yang sistematik (COTS Commercial-off-the-shelf) Proses Analisa Komponen Kebutuhan Modifikasi Mendesain sistem dg memanfaatkan komponen-komponen yang ada Pengembangan dan Integrasi

Sangat disukai dan penting (bagi bisnis) tetapi tanpa metode yang tepat malah akan mendapatkan sistem yang tidak robust

25

Avinanta Tarigan




Component-Reuse Oriented Development Proses Pengembangannya

26

Avinanta Tarigan




Process Iteration

Ide dasar: kebutuhan SELALU berubah selama pengembangan, sehingga perulangan proses dimana pengerjaan sebelumnya dirubah lagi adalah bagian pengembangan sistem secara keseluruhan Iterasi dapat diimplementasikan dalam setiap fase pengembangan generik Pendekatan berbasis perulangan proses Incremental development Spiral development

27

Avinanta Tarigan




Incremental Development Definition

Pengembangan dibagi menjadi bagian2 yang dapat berkembang secara bertambah (increments) Setiap bagian harus memenuhi fungsi-fungsi yang diperlukan Kebutuhan pengguna diprioritaskan dan prioritas tertinggi didahulukan dalam pengembangan Begitu dimulai, kebutuhan yang telah tertangani akan dibekukan sehingga memberikan tempat bagi kebutuhan lain untuk dapat berevolusi

28

Avinanta Tarigan




Incremental Development In a Diagram

29

Avinanta Tarigan




Incremental Development Kelebihan

Kebutuhan pengguna / kustomer dipenuhi pada setiap bagian yang selesai terlebih dahulu Bagian yang selesai terlebih dahulu menjadi prototipe Resiko rendah Bagian yang punya prioritas tertinggi dapat dites secara intensive

30

Avinanta Tarigan




eXtreme programming

Pendekatan baru Pengembangan bagian-bagian kecil dari fungsi sistem Bergantung kepada : improvemen kode yang konstan keikutsertaan user dalam pengembangan pairwise programming

31

Avinanta Tarigan




The Spiral Model (Boehm)

Proses direpresentasikan dalam aktivitas berbentuk spiral Setiap perulangan (loop) dalam spiral merepresentasikan sebuah fase dalam proses Fase-fase tidak fix (spesifikasi - design loop) dipilih sesuai dengan yang diperlukan Resiko selalu secara transparan dimonitor dan dipecahkan selama proses berlangsung

32

Avinanta Tarigan




The Spiral Model (Boehm)

33

Avinanta Tarigan




The Spiral Model (Boehm) 1

Mendefinisikan tujuan dalam 1 siklus spiral Tujuan spesifik harus didefinisikan sebagai output dari 1 siklus spiral

2

Indentifikasi Resiko, assasement, pemecahan Mencari semua resiko yang mungkin dan memecahkannya sebelum langkah berikutnya dimulai

3

Pengembangan dan Validasi Pengembangan sistem / software itu sendiri dan memvalidasinya sesuai dengan kebutuhan Pengembangan sesuai dengan model generik

4

Perencanaan berikutnya Review hasil dari 1 siklus proyek Merencanakan pengembangan berikutnya

34

Avinanta Tarigan


Pengujian Perangkat Lunak

Strategi Pengujian Secara Umum

Outline

35

1


2


3


Avinanta Tarigan




Strategi Pengujian

Berupa Rencana Pengujian Desain Pengujian Eksekusi Pengujian

Cukup fleksibel sehingga setiap proyek dapat mempunyai kasus pengujian yang berbeda Harus cukup detail sehingga dapat dijadikan tolok ukur kemajuan proyek Hasil: Dokumen Spesifikasi Pengujian → panduan bagi pelaksana dan milestone bagi manajemen

36

Avinanta Tarigan




Karakteristik Pengujian Generik

Memasukkan “formal technical reviews” untuk mengeliminasi error sebelum pengujian dimulai Dimulai dari komponen-komponen sistem sampai pada sistem secara keseluruhan Teknik pengujian dipilih sesuai dengan ketepatannya setiap waktu / kasus Dilaksanakan oleh pengembang PL atau tim independen Pengujian & Debugging tidak sama, tetapi debugging harus ada di setiap testing

37

Avinanta Tarigan




Organisasi Pengujian Perangkat Lunak

Perbedaan konsep Verifikasi (membuat PL dengan benar) dan Validasi (membuat PL yang benar) Problem Psikologi: Pengembang cenderung untuk memperlihatkan fitur sistem dan validasinya terhadap kebutuhan user Pelaksanaan oleh tim luar potensi membuat konflik dg pengembang

Tim luar bukan bertanggungjawab thd kualitas PL

38

Avinanta Tarigan




Kapan Pengujian Selesai ?

Problem: Tidak pernah selesai Biaya: Selesai begitu dana untuk Pengujian telah habis Kriteria Statistik (Musa & Ackerman) 95% kepercayaan terhadap sistem tsb apabila dalam 1000 jam sisem berjalan terdapat probabilitas 0.995 operasi PL yang tidak gagal

39

Avinanta Tarigan



Pengujian PL Berarsitektur Konvensional

Outline

40

1


2


3


Avinanta Tarigan




Proses Pengujian

41

Avinanta Tarigan




Proses Pengujian I Pengujian Unit Komponen-komponen diuji secara individual Pengujian terhadap kode program dan algoritma

Pengujian Modul Pengujian himpunan komponen-komponen yang saling berkaitan atau bergantungan

Pengujian Sub-Sistem Pengujian modul yang diintegrasikan kedalam satu sub-sistem. Fokus ada pada pengujian antar-muka

Pengujian Sistem Pengujian sistem secara keseluruhan Pengujian terhadap adanya “pembrojolan” (emergent properties) 42

Avinanta Tarigan




Proses Pengujian II

Pengujian Penerimaan Pengguna Pengujian Penerimaan Pengguna terhadap PL tersebut Validasi terhadap Kebutuhan Pengguna

43

Avinanta Tarigan




Testing Phases

44

Avinanta Tarigan




Pengujian Unit

45

Avinanta Tarigan




Pengujian Unit Antarmuka: untuk memastikan aliran data yang masuk dan keluar sesuai

Struktur Data Lokal memastikan integritas variabel lokal selama eksekusi

Kondisi Unit Pada Batas Limit unit selalu beroperasi dengan benar pada limit-limit tertentu

Independent Path algoritma yang berdiri sendiri beroperasi dengan benar

Error handling path algoritma untuk mendeteksi dan menangani error beroperasi dengan benar

46

Avinanta Tarigan




Kesalahan Umum

kesalahan aritmatika operasi menggunakan modus yang bercampur inisialisasi yang tidak benar presisi yang tidak terakurasi representasi simbolik yang tidak benar

47

Avinanta Tarigan




Pengujian Modul

48

Avinanta Tarigan




Pengujian Integrasi Sistem

Incremental Integration vs Big Bang Top-down Integration Depth First Integration Breadth First Integration Memverifikasi kontrol

Bottom-up Integration Stubs tidak diperlukan Clustering

49

Avinanta Tarigan




Pengujian Regresi dan Smoke

Pengujian berulang terhadap komponen / modul yang telah diuji sebelumnya akibat integrasi dengan yang belum diuji Smoke: integrasi bertahap dibuat setiap hari dalam bentuk “build” pengujian diulang pada tahap integrasi ini

Keuntungan Resiko integrasi diminimalisasi Kualitas produk meningkat Memudahkan diagnosa error dan koreksi Kemajuan proyek dapat dilihat dengan mudah

50

Avinanta Tarigan



Pengujian Dalam Konteks PBO

Outline

51

1


2


3


Avinanta Tarigan




Pengujian Dalam Konteks OO

Prinsip enkapsulasi dan information hiding Pengujian class-class dan penurunannya Detail algoritma dalam setiap class dan keturunannya

52

Avinanta Tarigan




Pengujian Integrasi Dalam Konteks OO

Pengujian Thread pengujian terhadap beberapa class yang tergabung dalam satu thread diuji terhadap input yang ditentukan sebelumnya

Pengujian Berdasarkan Penggunaan pengujian class terhadap penggunaannya di class yang lain pertama adalah pengujian independent class kedua adalah pengujian dependent class

Cluster Testing

53

Avinanta Tarigan



Pengujian Sistem

Outline

54

1


2


3


Avinanta Tarigan



Pengujian Sistem

Pengujian Sistem

Pengujian Recovery Bagaimana sistem dapat merekover dirinya thd suatu kesalahan

Pengujian Keamanan Bagaimana sistem dapat mempertahankan dirinya agar tidak masuk ke dalam “state of insecure”

Pengujian Stress Bagaimana sistem dapat bertahan beroperasi dalam tekanan “waktu” dan “pelayanan”

Pengujian Performa Bagaimana performa sistem dalam melaksanakan pekerjaannya

55

Avinanta Tarigan


End

Terimakasih

Perancangan Sistem Informasi

Recommend Documents