Perancangan Sistem Informasi

(1)

Perancangan Sistem Informasi

Perancangan Perangkat Lunak

Avinanta Tarigan

Gunadarma University

(2)

Outline

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

(3)

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

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)

(4)

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

Outline

Pengujian Sistem

(5)

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

(6)

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

(7)

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)

(8)

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

(9)

Outline

Pengujian Sistem

(10)

Aspek-aspek Dalam R/P-PL Problema

Mengapa Kita Harus Belajar PPL

(11)

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

(12)

Proses Pengembangan PL Definisi

Outline

Pengujian Sistem

(13)

Proses Pengembangan PL

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

1 Spesifikasi

Mendifinisikan bagaimana sistem harus bekerja, ruang lingkup, dan hambatan2nya

2 Pengembangan

Fase produksi: programming, dokumentasi, cek error, etc

3 Validasi dan verifikasi

Memvalidasi bahwa PL dapat memenuhi kebutuhan pengguna (requirement)

4 Evolusi

Merubah PL sesuai dengan perubahan kebutuhan pengguna

(14)

Proses Pengembangan PL 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

(15)

Outline

Pengujian Sistem

(16)

Proses Pengembangan PL Model Proses Pengembangan PL

The Waterfall Model

The Spirit

(17)

The Waterfall Model

As is

(18)

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

(19)

Evolutionary Development

Versioning dan Prototyping

(20)

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

(21)

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”

(22)

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

(23)

Formal System Development

Contoh Spesifikasinya Dalam TLA+

(24)

Formal System Development

Formal Transformation and Proofs

P1 ∧ P2 ∧ P3 ∧ P4 ≡ TRUE

(25)

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

(26)

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

(27)

Component-Reuse Oriented Development

Proses Pengembangannya

(28)

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

(29)

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

(30)

Incremental Development

In a Diagram

(31)

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

(32)

eXtreme programming

Pendekatan baru

Pengembangan bagian-bagian kecil dari fungsi sistem Bergantung kepada :

improvemen kode yang konstan

keikutsertaan user dalam pengembangan pairwise programming

(33)

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

(34)

The Spiral Model (Boehm)

(35)

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

(36)

Pengujian Perangkat Lunak Strategi Pengujian Secara Umum

Outline

Pengujian Sistem

(37)

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

(38)

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

(39)

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

(40)

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

(41)

Outline

Pengujian Sistem

(42)

Pengujian Perangkat Lunak Pengujian PL Berarsitektur Konvensional

Proses Pengujian

(43)

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

(44)

Proses Pengujian II

Pengujian Penerimaan Pengguna

Pengujian Penerimaan Pengguna terhadap PL tersebut Validasi terhadap Kebutuhan Pengguna

(45)

Testing Phases

(46)

Pengujian Unit

(47)

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

(48)

Kesalahan Umum

kesalahan aritmatika

operasi menggunakan modus yang bercampur inisialisasi yang tidak benar

presisi yang tidak terakurasi

representasi simbolik yang tidak benar

(49)

Pengujian Modul

(50)

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

(51)

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

(52)

Pengujian Perangkat Lunak Pengujian Dalam Konteks PBO

Outline

Pengujian Sistem

(53)

Pengujian Dalam Konteks OO

Prinsip enkapsulasi dan information hiding Pengujian class-class dan penurunannya

Detail algoritma dalam setiap class dan keturunannya

(54)

Pengujian Perangkat Lunak Pengujian Dalam Konteks PBO

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

(55)

Outline

Pengujian Sistem

(56)

Pengujian Perangkat Lunak 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

(57)

Perancangan Sistem Informasi