perancangan sistem informasi -...

Perancangan Sistem InformasiPerancangan Perangkat Lunak

Avinanta Tarigan

Gunadarma University

1 Avinanta Tarigan Perancangan Sistem Informasi

Outline

1 Aspek-aspek Dalam R/P-PLRekayasa Perangkat LunakProblema

2 Proses Pengembangan PLDefinisiModel Proses Pengembangan PL

3 Pengujian Perangkat LunakStrategi Pengujian Secara UmumPengujian PL Berarsitektur KonvensionalPengujian Dalam Konteks PBOPengujian Sistem


Pustaka I

Sommerville, Ian, “Software Engineering”, Addison-Wesley,1982

Pressman, Roger S, “Software Engineering: A Practitioner’sApproach”, Boston, Mass: McGraw-Hill, 2005

Parnas, David, “Software Engineering Programmes are notComputer Science Programmes”, Annals of SoftwareEngineering, 1998

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

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


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

Outline






Software / Perangkat Lunak

Program Komputer, Mekanikal yang dapat dengan mudahdibentuk dan dirubah

Produk Perangkat Lunak:

Generik :

untuk pengguna umumpengguna harus mengikuti apa yang telah dibuat olehprogrammer

Bespoke / Tailor-made :

dibuat khusus untuk sekelompok penggunadeveloper mengikuti requirement dari pengguna



Software Engineering I

Application of systematic, disciplined, quantifiable approachto 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. HoareDavid ParnasBarry 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)



Software Engineering II

Engineers belajar science + metoda untuk mengaplikasikannya

Membutuhkan pengetahuan: computer engineering & science,managemen, matematik, manajemen proyek, managementkualitas, software ergonomics, system engineering

Peneliti (scientist) fokus pada satu subyek dan mendalaminya,tetapi engineer harus memilik pengetahuan yang cukup luasdan melebar


Aspek-aspek Dalam R/P-PL Problema

Outline






Mengapa Kita Harus Belajar PPL

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



Karakteristik Software Yang Bagus

MaintainabilityPL harus dapat dengan mudah dirubah sesuai denganperubahan kebutuhan pengguna

DependabilityPL harus dapat dipercaya (trustworthy) sehingga penggunadapat menggantungkan sepenuhnya proses bisnis mereka

EfficiencyPL harus efisien dan tidak memakai resources yang tinggi

UsabilityPL harus dapat “digunakan” (usable) oleh penggunanyadalam memenuhi kebutuhan mereka


Proses Pengembangan PL Definisi

Outline






Proses Pengembangan PL

Himpunan dari aktifitas yang bertujuan untukmengembangkan PL atau evolusi dari PL

Secara generik:

1 SpesifikasiMendifinisikan bagaimana sistem harus bekerja, ruang lingkup,dan hambatan2nya

2 PengembanganFase produksi: programming, dokumentasi, cek error, etc

3 Validasi dan verifikasiMemvalidasi bahwa PL dapat memenuhi kebutuhan pengguna(requirement)

4 EvolusiMerubah PL sesuai dengan perubahan kebutuhan pengguna



Model Proses Pengembangan PL

Simplifikasi proses pengembangan PL dari perspektiv yangspesifik

Perspektiv:

Workflow - aliran aktivitasData-Flow based - aliran informasiRole/Action based - peran-peran pengembang

Beberapa model proses PL

Waterfall modelEvolutionaryFormal transformationIntegration from reusable componentsAgile and eXtreme Software Development


Proses Pengembangan PL Model Proses Pengembangan PL

Outline






The Waterfall ModelThe Spirit



The Waterfall ModelAs is



The Waterfall ModelProblem Dari Waterfall Model

Sangat sulit untuk mengakomodasi perubahan dalam proses

Tidak fleksibel dalam pemisahan proyek dalam beberapalangkah pengembangan

Tidak mudah untuk merespon perubahan

Dapat digunakan apabila kebutuhan pengguna sudah benar2dimengerti, dikuasai, diresapi dan tidak akan berubah selamapengembangan



Evolutionary DevelopmentVersioning dan Prototyping



Evolutionary DevelopmentProblema dan Pengejawantahannya

Problem:

Visibilitas proses tidak jelas terlihatSistem kadang2 tidak terstrukturMembutuhkan skill khusus (misalnya, bahasa untuk rapidprototyping)

Dapat digunakan dalam:

sistem interaktif yang kecil atau menengahmengembangkan bagian dari sistem yang besar (misalnya, userinterface)sistem yang life-cyclenya pendek



Formal System Development

Kebutuhan user dispesifikasikan dalam bentuk matematik

Bentuk matematik tsb ditransformasikan dalamabstraksi-abstraksi spesifikasi sampai pada program yangdapat dijalankan

Requirement Definiiton → Formal Specification →Formal Transformation → Executable Program →

Integration & System Testing

Transformasi tsb “correctness-preserving”, dapat denganmudah membuktikan bahwa program akhir sesuai denganspesifikasi awal

Pendekatan “Cleanroom”



Formal System DevelopmentPenggunaannya

investasi awal sangat tinggi

bias dalam penyusunan kebutuhan dapat diperkecil karenaanalisis detail sangat diperlukan dan mandatory

ketidaklengkapan dan ketidakkonsistenan dapat diidentifikasidan dibetulkan

penghematan dalam proyek yang biasanya disebabkan olehproblem dalam pendefinisian kebutuhan



Formal System DevelopmentContoh Spesifikasinya Dalam TLA+



Formal System DevelopmentFormal Transformation and Proofs

P1 ∧P2 ∧P3 ∧P4≡ TRUE



Formal System DevelopmentProblems and Applicability

Problema

Dibutuhkan kepala yang pintar dan terlatihTidak mudah (tidak mungkin) untuk memformalkan semuaaspek dalam sistem

Aplikasi

Critical systems : safety dan security



Component-Reuse Oriented DevelopmentDefinisi

Berdasarkan penggunaan kembali komponen-komponen PLdengan metoda yang sistematik (COTSCommercial-off-the-shelf)

Proses

Analisa KomponenKebutuhan ModifikasiMendesain sistem dg memanfaatkan komponen-komponenyang adaPengembangan dan Integrasi

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



Component-Reuse Oriented DevelopmentProses Pengembangannya



Process Iteration

Ide dasar:kebutuhan SELALU berubah selama pengembangan, sehinggaperulangan proses dimana pengerjaan sebelumnya dirubah lagiadalah bagian pengembangan sistem secara keseluruhan

Iterasi dapat diimplementasikan dalam setiap fasepengembangan generik

Pendekatan berbasis perulangan proses

Incremental developmentSpiral development



Incremental DevelopmentDefinition

Pengembangan dibagi menjadi bagian2 yang dapatberkembang secara bertambah (increments)

Setiap bagian harus memenuhi fungsi-fungsi yang diperlukan

Kebutuhan pengguna diprioritaskan dan prioritas tertinggididahulukan dalam pengembangan

Begitu dimulai, kebutuhan yang telah tertangani akandibekukan sehingga memberikan tempat bagi kebutuhan lainuntuk dapat berevolusi



Incremental DevelopmentIn a Diagram



Incremental DevelopmentKelebihan

Kebutuhan pengguna / kustomer dipenuhi pada setiap bagianyang selesai terlebih dahulu

Bagian yang selesai terlebih dahulu menjadi prototipe

Resiko rendah

Bagian yang punya prioritas tertinggi dapat dites secaraintensive



eXtreme programming

Pendekatan baru

Pengembangan bagian-bagian kecil dari fungsi sistem

Bergantung kepada :

improvemen kode yang konstankeikutsertaan user dalam pengembanganpairwise programming



The Spiral Model (Boehm)

Proses direpresentasikan dalam aktivitas berbentuk spiral

Setiap perulangan (loop) dalam spiral merepresentasikansebuah fase dalam proses

Fase-fase tidak fix (spesifikasi - design loop) dipilih sesuaidengan yang diperlukan

Resiko selalu secara transparan dimonitor dan dipecahkanselama proses berlangsung




1 Mendefinisikan tujuan dalam 1 siklus spiral

Tujuan spesifik harus didefinisikan sebagai output dari 1 siklusspiral

2 Indentifikasi Resiko, assasement, pemecahan

Mencari semua resiko yang mungkin dan memecahkannyasebelum langkah berikutnya dimulai

3 Pengembangan dan Validasi

Pengembangan sistem / software itu sendiri danmemvalidasinya sesuai dengan kebutuhanPengembangan sesuai dengan model generik

4 Perencanaan berikutnya

Review hasil dari 1 siklus proyekMerencanakan pengembangan berikutnya


Pengujian Perangkat Lunak Strategi Pengujian Secara Umum

Outline






Strategi Pengujian

Berupa

Rencana PengujianDesain PengujianEksekusi Pengujian

Cukup fleksibel sehingga setiap proyek dapat mempunyaikasus pengujian yang berbeda

Harus cukup detail sehingga dapat dijadikan tolok ukurkemajuan proyek

Hasil: Dokumen Spesifikasi Pengujian → panduan bagipelaksana dan milestone bagi manajemen



Karakteristik Pengujian Generik

Memasukkan “formal technical reviews” untuk mengeliminasierror sebelum pengujian dimulai

Dimulai dari komponen-komponen sistem sampai pada sistemsecara keseluruhan

Teknik pengujian dipilih sesuai dengan ketepatannya setiapwaktu / kasus

Dilaksanakan oleh pengembang PL atau tim independen

Pengujian & Debugging tidak sama, tetapi debugging harusada di setiap testing



Organisasi Pengujian Perangkat Lunak

Perbedaan konsep Verifikasi (membuat PL dengan benar) danValidasi (membuat PL yang benar)

Problem Psikologi:

Pengembang cenderung untuk memperlihatkan fitur sistemdan validasinya terhadap kebutuhan userPelaksanaan oleh tim luar potensi membuat konflik dgpengembang

Tim luar bukan bertanggungjawab thd kualitas PL



Kapan Pengujian Selesai ?

Problem: Tidak pernah selesai

Biaya: Selesai begitu dana untuk Pengujian telah habis

Kriteria Statistik (Musa & Ackerman)

95% kepercayaan terhadap sistem tsbapabila dalam 1000 jam sisem berjalan terdapat probabilitas0.995 operasi PL yang tidak gagal


Pengujian Perangkat Lunak Pengujian PL Berarsitektur Konvensional

Outline






Proses Pengujian



Proses Pengujian I

Pengujian Unit

Komponen-komponen diuji secara individualPengujian terhadap kode program dan algoritma

Pengujian Modul

Pengujian himpunan komponen-komponen yang salingberkaitan atau bergantungan

Pengujian Sub-Sistem

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

Pengujian Sistem

Pengujian sistem secara keseluruhanPengujian terhadap adanya “pembrojolan” (emergentproperties)



Proses Pengujian II

Pengujian Penerimaan Pengguna

Pengujian Penerimaan Pengguna terhadap PL tersebut

Validasi terhadap Kebutuhan Pengguna



Testing Phases



Pengujian Unit



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 beroperasidengan benar



Kesalahan Umum

kesalahan aritmatika

operasi menggunakan modus yang bercampur

inisialisasi yang tidak benar

presisi yang tidak terakurasi

representasi simbolik yang tidak benar



Pengujian Modul



Pengujian Integrasi Sistem

Incremental Integration vs Big Bang

Top-down Integration

Depth First IntegrationBreadth First IntegrationMemverifikasi kontrol

Bottom-up Integration

Stubs tidak diperlukanClustering



Pengujian Regresi dan Smoke

Pengujian berulang terhadap komponen / modul yang telahdiuji 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 diminimalisasiKualitas produk meningkatMemudahkan diagnosa error dan koreksiKemajuan proyek dapat dilihat dengan mudah


Pengujian Perangkat Lunak Pengujian Dalam Konteks PBO

Outline






Pengujian Dalam Konteks OO

Prinsip enkapsulasi dan information hiding

Pengujian class-class dan penurunannya

Detail algoritma dalam setiap class dan keturunannya



Pengujian Integrasi Dalam Konteks OO

Pengujian Thread

pengujian terhadap beberapa class yang tergabung dalam satuthreaddiuji terhadap input yang ditentukan sebelumnya

Pengujian Berdasarkan Penggunaan

pengujian class terhadap penggunaannya di class yang lainpertama adalah pengujian independent classkedua adalah pengujian dependent class

Cluster Testing


Pengujian Perangkat Lunak Pengujian Sistem

Outline





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


End

Terimakasih

perancangan sistem informasi -...

Documents