pertemuan 1 pengenalan rekayasa perangkat · pdf fileperawatan (maintenance) ... biaya...

Pertemuan 1

PENGENALANPENGENALANREKAYASA PERANGKAT

LUNAK

Pokok Bahasan dalam RPL :

� RPL sebagai produk dan sebagai produk� Konsep manajemen proyek� Proses pembangunan PL dan metrik proyek� Perencanaan proyek PL� Perencanaan proyek PL� Manajemen resiko dlm pelaksanaan proyek� Penjadwalan dan penelusuran proyek pembangunan PL� Jaminan kualitas PL� Manajemen konfigurasi PL� Rekayasa sistem ke arah CB

Pokok Bahasan dalam RPL (lanjutan)

� Konsep dan prinsip analisis� Pemodelan analisis� Konsep dan prinsip desain� Metode desain� Metode desain� Implementasi pembangunan� Teknik pengujian perangkat� Strategi perancangan PL� CASE tool pembangunan PL

• Pressman, RS., 2008, Software Engineering: APractitioner’s Approach, New York: McGraw-Hill

Buku Referensi :

• Sommerville, I, 2007, Software Engineering, AddsionWesley

Rekayasa Perangkat Lunak� Perangkat Lunak? (Software??)� Rekayasa Perangkat lunak-RPL?� (Software engineering-SE??)� Rekayasa sistem-RS? (system engineering-SyE??)� Evolusi Perangkat Lunak� Evolusi Perangkat Lunak� Computer Science vs RPL� RPL vs RS ??� Pelaku yang berhubungan dengan Rekayasa

Perangkat Lunak� Mitos yang ada berkembang� Tantangan dalam Pengembangan Perangkat Lunak

Definisi Perangkat Lunak (PL)

� IEEE-Standar Glossary of Software EngineeringTerminology, 1990:“Computer programs, procedures, and possibly associateddocumentation and data pertaining to the operation of acomputer system.”computer system.”Maksudnya :Perangkat lunak merupakan kumpulan dari program, prosedur,dan dokumen data lain yang saling berhubungan yangmerepresentasikan masalah di dunia nyata yangdikonfigurasikan dalam sebuah bentuk aplikasi yang harusdikerjakan komputer

Produk Perangkat Lunak

� Perangkat lunak tidak sama dengan produk perangkatkeras

� Produk perangkat lunak dikembangkan (developed)atau direkayasa (engineered). Sebagian besaratau direkayasa (engineered). Sebagian besardikembangkan atau dibangun berdasrkan pemesanandan sebagian kecil dibuat secara paket.

� Tidak dipabrikkan seperti pabrik perangkat keras, misalkomputer, mobil.

� Perangkat lunak secara pemakaian tidak pernah AUSlayaknya perangkat keras

Produk Perangkat Lunak (2)

� 2 Bentuk produk perangkat lunak:1. Produk Generik (Umum)

Sistem stand-alone standar yang diproduksi olehorganisasi pengembang dan dijual ke pasar terbuka keorganisasi pengembang dan dijual ke pasar terbuka kesiapapun yg membelinya. Biasa disebut sebagai softwareshrink-wrapped. Contoh : word processor, Database.

2. Produk pesanan (yang disesuaikan)Sistem yang dipesan oleh pelanggan tertentu.Dikembangkan khusus bagi pelanggan oleh kontraktorperangkat lunak. Contoh : Sistem untuk mendukungproses bisnis tertentu dan sistem kontrol lalu lintas udara

Produk Perangkat Lunak (3)

� Perbedaan PENTING antara 2 bentuk perangkat lunak :

� Pada produk generik, organisasi yangmengembangkan perangkat lunak mengontrolspesifikasi perangkat lunak.

� Pada produk pesanan, spesifikasi biasanyadikembangkan dan dikontrol oleh organisasi yangmembeli perangkat lunak tersebut.

Produk Perangkat Lunak (4)� Karakteristik perangkat lunak yang baik:

� Usability : Mempunyai daya guna yang tinggi� be reliable : Mampu diandalkan� maintenability : Mudah dirawat/diperbaiki� Efficiency : perangkat perangkat lunak tidak boros

dalam menggunakan sumber daya sistem sepertidalam menggunakan sumber daya sistem sepertimemory & processor

� eye cathcing user interface : Mempunyai antarmuka ygmenarik

� long life time : Mempunyai siklus hidup yang cukuplama

� Mempunyai kinerja sesuai fungsi yang dibutuhkanpemakai

Jenis-jenis aplikasi Perangkat Lunak � Perangkat Lunak Sistem (System software)

Adalah sekumpulan program yang ditulis untuk melayaniatau menunjang program lainnya.

Misalnya : compiler, editor, komponen-komponen sistemoperasi, driver dan prosesor telekomunikasi.

� Perangkat lunak waktu nyata (Realtime Software)

Perangkat lunak yang berfungsi untuk memonitor,menganalisis, mengontrol dan memberikan laporan tentangkejadian dunia nyata dan meresponnya dalam waktukurang dari 1 menit.

Misal: pengontrol arus udara, pengontrol keasaman tabungreaksi (pressman punya), pengontrol reaksi nuklir, dll

Jenis-jenis aplikasi Perangkat Lunak (2)

� Perangkat Lunak Teknik Dan Ilmu Pengetahuan(Scientific & Engineering Software)

Perangkat lunak yg menangani bidang teknik dan ilmupengetahuan secara rinci

Misal: simulasi astronomi, vulkanologi, analisis otomatif,dinamika orbit pesawat ruang angkasa, biologi molekuler,dinamika orbit pesawat ruang angkasa, biologi molekuler,otomasi pabrik, dll

� Embeded System

Perangkat lunak yg ditempelkan/dilekatkan pada perangkatlainnya (lunak/keras).

Misal: pada kamera digital, GPS, automobil, microwave,kulkas cerdas, dll


� Perangkat Lunak Pengolah Data (Data Processing)

Perangkat lunak yg khusus digunakan untuk mengolahdata dan menghasilkan suatu keputusan tertentu.

Misal: billing telepon, pengolah statistikMisal: billing telepon, pengolah statistik

� Perangkat Lunak Sistem Informasi (InformationSystem)

Perangkat lunak yg mampu memberi informasi dari suatusistem secara lebih detail.

Misal: web site, perpustakaan digital, dll


� Perangkat Lunak Sensor

Perangkat lunak yg mampu mengukur dan mengatursuatu keadaan khusus, kadang digolongkan dalamembedded system juga.

Misal: pengatur cuaca, pengatur suhu ruangan, dll

� Perangkat Lunak Komunikasi (CommunicaionSoftware)

Perangkat lunak yg berfungsi untuk menghubungkan ataumengkomunikasikan suatu objek satu dengan lainnya.

Misal: router, handphone, dll


� Perangkat Lunak Pengolah Grafis

Perangkat lunak yang digunakan untuk melakukanperancangan grafis

Misal: pembuatan film, pembuatan posterMisal: pembuatan film, pembuatan poster

� Perangkat Lunak Kecerdasan

Perangkat lunak yg menggunakan algoritma no-numerisuntuk memecahkan masalah kompleks yg tdk sesuaiuntuk perhitungan atau analisis secara langsung

Misal: sistem pakar, pembuktian teorema, game strategi,jaringan saraf tiruan, dll

Evolusi Perangkat Lunak � Perangkat lunak telah semakin berkembang sejak

pertama kali diciptakan tahun 1945

� Fokus utama pembuatannya untuk mengembangkanpraktik dan teknologi dalam meningkatkan produktivitaspara praktisi pengembang PL dan kualitas aplikasi ygpara praktisi pengembang PL dan kualitas aplikasi ygdapat digunakan oleh pemakai

� Evolusi dipicu adanya tuntutan bisnis dan lingkungankerja yang berkembang sangat dinamis

Evolusi Perangkat Lunak (2)

� Era I (1945 – 1960):

� Munculnya teknologi perangkat keras di tahap awal

� Penggunaan perangkat lunak yg berorientasi batch

� Distribusi perangkat lunak masih terbatas� Distribusi perangkat lunak masih terbatas

� Didominasi perangkat lunak model custome

� Munculnya istilah software engineering (akhir 1950-an/awal 1960-an)

� Belum didefinisikan secara jelas tentang aspek–software engineering


� Era II (1960 – 1970)

� Disebut era krisis perangkat lunak (software crisis).

� Penggunaan perangkat lunak sudah meluas

� Telah hadir perusahaan yang membangun software� Telah hadir perusahaan yang membangun software(software house)

� Perangkat lunak sdh mengenal multiprogram, multiuser,real-time, dan penggunaan database.

Evolusi Perangkat Lunak (4) � Era II (Lanjutan)

� Banyak project PL yg gagal

� Over budget/anggaran

� Berakibat rusak fisik dan kematian� Berakibat rusak fisik dan kematian

� Meledaknya Roket Ariane , kesalahan perintah dlm PL

� Dua konferensi ttg software engineering:

� Disponsori Komite Sains NATO

� Tahun 1968 dan 1969

� Profesi resmi bidang software engineering


� Era III (1975 – 1985)

� Pengembangan sistem mengarah ke konsep sistemterdistribusi.

� Penerapan sistem embeded intelligence� Penerapan sistem embeded intelligence

� Harga perangkat keras sudah jauh lebih murahsehingga pemakaian meluas

� Pemanfaatan jaringan global dan lokal serta sudahdiperkenalkan komunikasi digital


� Era IV (1985 – 2000)

� Kemampuan PC sudah setara dengan komputermainframe

� Penerapan teknologi yang berorientasi pada objek� Penerapan teknologi yang berorientasi pada objek

� Implementasi sistem pakar

� Jaringan saraf tiruan

� Komputasi paralel

� Jaringan komputer sudah semakin canggih


� Era V (2000 – sekarang)

� Penggunaan media digital

� Media web berkembang pesat

� Wireless sudah meluas� Wireless sudah meluas

� Teknologi meluas hingga di mobile computing, mobileprogramming

� Perangkat keras sudah semakin kecil namun powerfull

� Dilakukan berbagai penelitian yang menghasilkanmodel proses/paradigma pengembangan PL utkmengatasi krisis PL

Krisis Perangkat Lunak� Masalah yang muncul:

� Estimasi jadwal dan biaya yang seringkali tidak tepat

� Produktivitas orang-orang software yang tidak dapat

� mengimbangi permintaan software

� Kualitas software yang kurang baik.

� Kurangnya pengetahuan tentang:

� Bagaimana mengembangkan software

� Bagaimana memelihara software yang ada, yangberkembang dalam jumlah besar

� Bagaimana mengimbangi permintaan software yangmakin besar.

� Mitos1:

� Kita tidak perlu mengubah pendekatan terhadappengembangan software, karena jenis pemrogramanyang kita lakukan sekarang ini sudah kita lakukan 10

Mitos Dalam Perangkat Lunak (Management)

yang kita lakukan sekarang ini sudah kita lakukan 10tahun yang lalu.

� Realitasnya : Walau hasil program sama, produktivitasdan kualitas software harus ditingkatkan denganmenggunakan pendekatan software developments

� Mitos2:� Kita sudah mempunyai buku yang berisi standarisasi dan

prosedur untuk pembentukan software.

� Realitasnya : Memang buku tersebut ada, tetapi apakah

Mitos Dalam Perangkat Lunak (Management) (2)

� Realitasnya : Memang buku tersebut ada, tetapi apakahbuku tersebut sudah dibaca atau buku tersebut sudahketinggalan jaman ( out of date ).

� Mitos3:� Jika kita tertinggal dari jadwal yang ditetapkan, kita

menambah beberapa programmer saja. Konsep ini seringdisebut Mongolian harde concept.

� Mitos1:

� Pernyataan tujuan umum sudah cukup untuk memulaipenulisan program. Penjelasan yang lebih rinci akanmenyusul kemudian.

Mitos dalam perangkat lunak (Customer)

menyusul kemudian.

� Realitasnya : Definisi awal yang buruk adalah penyebabutama kegagalan terhadap usaha-usaha pem-bentukkansoftware. Penjelasan yang formal dan terinci tentanginformasi fungsi performance interface, hambatan desaindan kriteria validasi adalah penting. Karakteristik di atasdapat ditentukan hanya setelah adanya komunikasi antaracustomer dan developer.

� Mitos2:� Kebutuhan proyek yang terus menerus berubah dapat

dengan mudah diatasi karena software itu bersifatfleksibel.

Mitos dalam perangkat lunak (Customer)

fleksibel.

� Realitasnya : memang benar bahwa kebutuhan softwareberubah, tetapi dampak dari peru-bahan berbeda dariwaktu ke waktu.

� Mitos1:� Tidak ada metode untuk analisis disain dan testing terhadap

suatu pekerjaan, cukup menuju ke depan terminal dan mulaicoding.

� Realitasnya : Metode untuk analisis desain dan testingdiperlukan dalam pengembangan software.

Mitos Dalam Perangkat Lunak (Praktisi)

diperlukan dalam pengembangan software.

� Mitos2:� Segera setelah software digunakan, pemeliharaan dapat

diminimalisasikan dan diatasi dengan cara “CATCH AS CATCHCAM”.

� Realitasnya : Diperlukan budget yang besar dalam maintenancesoftware. Pemeliharaan software harus diorganisir, direncanakandan dikontrol seolah-olah sebagai suatu proyek besar dalamsebuah organisasi.

� Mitos2:� Kebutuhan proyek yang terus menerus berubah dapat

dengan mudah diatasi karena software itu bersifatfleksibel.

� Realitasnya : memang benar bahwa kebutuhan software

Mitos dalam perangkat lunak (Management)

� Realitasnya : memang benar bahwa kebutuhan softwareberubah, tetapi dampak dari peru-bahan berbeda dariwaktu ke waktu.

Definisi Rekayasa Perangkat Lunak (RPL)

RPL atau Software Engineering (SE) � Disiplin ilmu yangmembahas semua aspek produksi perangkat lunak, mulaidari tahap awal spesifikasi sistem sampai pemeliharaansistem setelah digunakan. Perangkat Lunak yang dibuatharus mampu:harus mampu:

� Tepat waktu

� Tepat anggaran

� Meningkatkan kinerja

� Mengoperasikan prosedur sistem dengan benar

Definisi Rekayasa Perangkat Lunak (Lanjutan)

Ada 2 istilah kunci :

1. “disiplin rekayasa” � Perekayasa membuat suatu alatbekerja. Menerapkan teori, metode, dan alat bantu yangsesuai, selain itu mereka menggunakannya denganselektif dan selalu mencoba mencari solusi terhadapselektif dan selalu mencoba mencari solusi terhadappermasalahan.

2. “semua aspek produksi perangkat lunak” � RPL tidakhanya berhubungan dengan proses teknis daripengembangan perangkat lunak tetapi juga dengankegiatan seperti Manajemen proyek PL danpengembangan alat bantu, metode, dan teori untukmendukung produksi PL.

• Computer science lebih memperhatikan teori

& metode komputerisasi, sedangkan software

engineering menyangkut masalah praktikal

pembuatan dan delivery perangkat lunak

Perbedaan RPL dengan Computer science

pembuatan dan delivery perangkat lunak

• Software engineering merupakan bagian dari

system engineering, dimana sistem

engineering memperhatikan semua aspek

pembuatan sistem berbasis komputer

termasuk perangkat keras, perangkat lunak &

proses

Perbedaan RPL dengan Rekayasa Sistem (RS)?

� Rekayasa Sistem (RS) berkaitan dengan semua aspekdalam pembangunan sistem berbasis komputertermasuk hardware, rekayasa PL dan proses.

� RPL adalah bagian dari rekayasa sistem yang meliputipembangunan PL, infrasktruktur, kontrol, aplikasi dandatabase pada sistem.

� Tantangan warisanDikembangkan bertahun-tahun dengan orang-orangyang berbeda-beda

� Tantangan heterogensisDalam hal distribusi & teknologi

Tantangan dalam Rekayasa Perangkat Lunak

Dalam hal distribusi & teknologi� Tantangan pengiriman

Bagaimana mengirim sistem yang besar dan komplekscepat dan dengan kualitas tetap terjaga.

Pelaku Dalam RPL� Manajer1. Manajer proyek2. Manajer konfigurasi3. Manajer penjamin kulitas PL4. Manajer bidang lainnya (sesuai kebutuhan

� Software Developer1. Analis sitem2. Desainer3. Programmer4. Inspektor PL5. Pengontrol perubahan

� Pendukung 1. Staf administrasi2. Humas3. Pencatat teknis4. Administrator database

Pelaku Dalam RPL (Lanjutan)

4. Administrator database5. Administrator jaringan

Pertemuan 2

SOFTWARE DEVELOPMENT SOFTWARE DEVELOPMENT LIFE CYCLE (SDLC)

POKOK BAHASAN

� Biaya PL

� Software Quality Attribute

� Standar kualitas

� Takaran Jaminan Kualitas� Takaran Jaminan Kualitas

� CASE TOOLS

� Siklus Hidup Perangkat Lunak

(SWDLC/Software Development Life Cycle)

BIAYA PERANGKAT LUNAK (SOFTWARE COST)

�Terkadang mendominasi biaya sistem secara keseluruhan�Biaya terbesar untuk perangkat lunak terletak pada proses

perawatan (maintenance) dibanding biaya pembuatannya(develop)

�Biaya pengadaan perangkat lunak yang di pasang pada PCsering lebih besar dibandingkan dengan harga perangkatkerasnya kec. Di negara-negara yang tidak menghargai HAKIkerasnya kec. Di negara-negara yang tidak menghargai HAKI

�Biaya perangkat lunak secara kasar sebesar 60% dari biayauntuk pembangunan dan 40% untuk pengujian

�Secara umum besarnya biaya bervariasi tergantung pada tipesistem yang dibangun dan kebutuhan sistem seperti kinerja dankehandalan sistem

�Biaya distribusi tergantung pada model pembangunan yangdigunakan

SOFTWARE QUALITY ATTRIBUTE (1)

Ciri-ciri kualitas menurut lembaga penjamin mutu PL (ISO,ANSI, IEEE, dll):

� Correctness (kebenaran)

� Kesesuaian antara kode program dg spesifikasi

� Kebebasan aplikasi aktual pada sistem PL

� Reliability (tahan uji)

� Didasari pada correctness dan availability(ketersediaannya)

� Sebagai suatu kemungkinan bahwa sistem ini mampumemenuhi suatu kegunaan (tergantung spesifikasinya)untuk sejumlah masukan percobaan di bawah kondisimasukan dan rentang waktu yang telah ditentukan.

� User Friendliness (mudah digunakan)

� Adequacy (kecukupan)

� Learnability (mudah dipelajari)

� Robustness (antisipasi kesalahan)

� Maintenatibility (mudah dirawat)

SOFTWARE QUALITY ATTRIBUTE (2)

� Maintenatibility (mudah dirawat)

� Readability (mudah dibaca)

� Extensibility (mudah diperluas)

� Testability (mudah untuk diuji/ditelusuri)

� Efficiency (efisiensi)

� Portability (mudah didistribusikan)

UKURAN JAMINAN KUALITAS (1)

� Ukuran membangun (constructive measures)� Aplikasi yg konsisten pada metode di seluruh fase

proses pembangunan

� Penggunaan perlatan/ tools yang memadai

� Pembangunan PL pd basis kualitas yg tinggi di akhirtahapan

� Perawatan yang konsisten pada dokumenasipengembangan

� Ukuran analitik (analytical measures)� Analisis program yang statis

� Analisis program yang dinamis

� Pemeilihan test case yang sistematis

� Pencatatan yang konsisten pada analisis produk

� Ukuran Organisasi (Organization Measures)� Pengalaman pengembang (developer) dalam

mempelajari strategi dan teknik yang tepat dalammembangun PL

UKURAN JAMINAN KUALITAS (2)

KRISIS PERANGKAT LUNAK

� Masalah yang muncul:� Estimasi jadwal dan biaya yang seringkali tidak tepat� Produktivitas orang-orang software yang tidak dapat

mengimbangi permintaan software� Kualitas software yang kurang baik.

� Kurangnya pengetahuan tentang:� Bagaimana mengembangkan software� Bagaimana memelihara software yang ada, yang

berkembang dalam jumlah besar� Bagaimana mengimbangi permintaan software yang

makin besar.

KODE ETIK PROFESI

� Konfidensialitas (menghormati klien)

� Tidak boleh menerima pekerjaan di luar

� kompetensinya

� Hak kekayaan intelektual (HaKI)� Hak kekayaan intelektual (HaKI)

� Penyalahgunaan komputer, hack, crack,

KODE ETIK INTERNASIONAL� Digagas oleh masyarakat profesional di Amerika (1999) yang

tergabung dalam ACM/IEEE� Makna yang terkandung:

� Prinsip-prinsip kesepakatan yang dihubungkan dengan tingkahlaku dan keputusan yang dibuat oleh para ahli profesional

� Masyarakat profesional: praktisi, pengajar, manajer, supervisor,pengambil kebijakan.

� Yang diatur:� Masyarakat dan kepentingannya� Klien dan atasan (pelayanan terbaik)� Produk (jaminan mutu)� Manajemen� Profesi� Kolega� Diri sendiri (ada usaha untuk mengupdate ipteknya)

CASE TOOLS

� CASE (Computer Aided Software Engineering)� Suatu peralatan baik HW maupun SW komputer yang

digunakan untuk menyediakan pendukung otomatisdalam aktivitas pembangunan PL.

� Tujuanmeningkatkan produktivitas dalam proses pembangunanPL secara signifikanPL secara signifikan

� Dikelompokkan dalam 2 kategori:1. Upper-CASE

Mendukung aktivitas proses pembangunan tahap awal(tahap analisis kebutuhan dan desain)

2. Lower-CASEMendukung aktivitas pembangunan di tahap akhirprogramming, debuging, dan testing)

Penggunaan CASE tools:� Graphical Editors

Digunakan untuk membuat model sistem� Data Dictionaries

Digunakan untuk mengatur unit-unit proyek� GUI Builders

Digunakan untuk mengkonstruksi antarmuka pemakai� Debugger

CASE TOOLS (2)

� DebuggerDigunakan untuk mencari kesalahan yg mungkin terjadi

� Automated TranslatorsDigunakan untuk pembangkitan source code program otomatis

� Compilator IntegratedDigunakan membuat antarmuka, koding, hingga membentukaplikasi yg bisa dijalankan

� Instalator KitDigunakan untuk membuat file instalasi/setup

SOFTWARE DEVELOPMENTLIFE CYCLE (SDLC)

Proses Generik� Spesifikasi

Apa yang harus dilakukan oleh perangkat lunak danbatasan/kendala pengembangannya

� PengembanganProses memproduksi sistem perangkat lunakProses memproduksi sistem perangkat lunak

� ValidasiPengujian perangkat lunak terhadap keinginan pengguna

� EvolusiPerubahan perangkat lunak berdasarkan perubahankeinginan.

MODEL PROSES RPL

� Model Waterfall, � Model Prototyping, � Model Evolutionary� Model Spiral� Reuse Based Development� Reuse Based Development

WATERFALL MODEL

Pemodelan

Sistem/

Informasi

Requirement Definitions

System andsoftware designsoftware design

Implementationand unit testing

Integr ation andsystem testing

Operation andmaintenance

� Requirements Analysis And Definition

Pembentukan kebutuhan

� System And Software Design

Mengubah kebutuhan-kebutuhan menjadi bentukkarakteristik yang dimerngerti perangkat lunak

WATERFALL MODEL (2)

� Implementation And Unit Testing

Penulisan program

� Integration And System Testing

Memeriksa program, mencari kesalahan

� Operation And Maintenance

Pemeliharaan sistem, menambahkan fungsi

WATERFALL MODEL (3)

Problems Model Waterfall

1. Jarang sekali proyek yang prosesnya bisa dilakukansecara sequencial.

2. Sukar bagi customer untuk secara explisitmengemukakan semua kebutuhannya.mengemukakan semua kebutuhannya.

3. Customer harus sabar.

4. Developer sering menunda pekerjaan. Anggota timharus menunggu anggota lainnya

5. menyelesaikan tugasnya.

PROTOTYPE MODEL

MendengarkanPelanggan

MembangunKonstruksi(prototipe)

Uji Pelanggan(evaluasi)

� Prototype Paradigm dimulai dengan mengumpulkankebutuhan-kebutuhan customer.

� Developer dan customer bertemu dan mendefinisikanobyektif software secara menyeluruh, mengidentifikasikebutuhan-kebutuhan yang diketahui dari area pekerjaan.

� Setelah itu dibuat Quick Design.

PROTOTYPE MODEL (2)

� Setelah itu dibuat Quick Design.� Quick Design difokuskan pada representasi aspek software

yang bisa dilihat customer/user (misal: format input danoutput).

� Quick Design cenderung ke pembuatan prototipe.� Prototipe dievaluasi customer/user dan digunakan untuk

menyempurnakan kebutuhan software yang akandikembangkan.

PROTOTYPE MODEL (2)

� Sering terjadi customer menjabarkan objektif umummengenai software yang diminta, tetapi tidak bisamendefinisakan input, proses, output yang dimintasecara detail.

� Disisi lain, developer menjadi tidak yakin terhadapefisiensi algoritma, kemampuan adaptasi terhadapefisiensi algoritma, kemampuan adaptasi terhadapsistem operasi, atau bentuk interaksi mesin denganorang.

� Untuk mengatasi situasi tersebut, bisa digunakanpendekatan Prototype Paradigm.

PROTOTYPE MODEL (3)

Problems Prototyping Model� Customer melihat prototipe tersebut sebagai versi dari

software.� Pada saat produk tersebut harus dibangun ulang

supaya level kualitas bisa terjamin,� Customer akan mengeluh dan meminta sedikit

perubahan saja supaya prototipe tersebut bisaperubahan saja supaya prototipe tersebut bisaberjalan.

� Development membuat implemetasi yang kompromitasdengan tujuan untuk memperoleh prototipe pekerjaansecara cepat.� Dampaknya adalah sistem operasi atau bahasa

pemrograman yang dipergunakan tidak tepat,algoritma tidak efisien.

EVOLUTIONARY MODEL

Penjelasan :

1. Kombinasikan elemet-element dari waterfall dengan sifatiterasi/perulangan.

2. Element-element dalam waterfall dikerjakan denganhasil berupa produk dengan

EVOLUTIONARY MODEL INCREMENTAL (2)

3. Spesifikasi tertentu, kemudian proses dimulai dari fasepertama hingga akhir dan menghasilkan produk denganspesifikasi yang lebih lengkap dari yang sebelumnya.

4. Demikian seterusnya hingga semua spesifikasi memenuhikebutuhan yang ditetapkan oleh pengguna.

5. Produk hasil increment pertama biasanya produk inti(core product), yaitu produk yang memenuhi kebutuhandasar. Produk tersebut digunakan oleh pengguna ataumenjalani review/ pengecekan detil. Hasil reviewtersebut menjadi bekal untuk pembangunan padaincrement berikutnya. Hal ini terus dikerjakan sampaiproduk yang komplit dihasilkan.


produk yang komplit dihasilkan.6. Model ini cocok jika jumlah anggota tim

pengembang/pembangun PL tidak cukup.7. Mampu mengakomodasi perubahan secara fleksibel.8. Produk yang dihasilkan pada increment pertama

bukanlah prototype, tapi produk yang sudah bisaberfungsi dengan spesifikasi dasar.

Kekurangan Incremental Model:

� Hanya cocok untuk proyek berukuran kecil (tidak lebihdari 200.000 baris coding)

� Mungkin terjadi kesulitan untuk memetakan kebutuhanpengguna ke dalam rencana spesifikasi masing-masing hasil increment


masing hasil increment

EVOLUTIONARY MODEL SPIRAL

Penjelasan :� Customer Comunication

Membangun komunikasi yang baik dengan pelanggan� Planning

Mendefinisikan sumber, batas waktu, informasi-informasi lain seputarproyek

� Risk Analyst

EVOLUTIONARY MODEL SPIRAL (2)

Identifikasi resiko management dan teknis� Engineering

Pembangunan contoh-contoh aplikasi misalnya prototype� Construction and release

Pembangunan, test, install dan report� Customer Evaluation

Mendapatkan feedback dari pengguna berdasarkan evaluasi pada faseengineering dan fase instalasi

� Pada model spiral, resiko sangat dipertimbangkan.Resiko adalah sesuatu yang mungkin mengakibatkankesalahan.

� Model spiral merupakan pendekatan yang realistikuntuk Perangkat Lunak berskala besar.

� Pengguna dan pembangun bisa memahami dengan

EVOLUTIONARY MODEL SPIRAL (3)

� Pengguna dan pembangun bisa memahami denganbaik software yang dibangun karena setiapkemajuan yang dicapai selama proses dapat diamatidengan baik. Namun demikian, waktu yang cukuppanjang mungkin bukan pilihan bagi pengguna, karenawaktu yang lama sama dengan biaya yang lebih besar.

REUSE BASEDA. Software Re-engineering

� Apakah itu?Restrukturisasi atau menulis ulang sebagian ataukeseluruhan dari sistem yang telah ada tanpa merubahfungsionalitasnya.

� Kapan?� Kapan?Ketika sebagian tetapi tidak semua sub sistem yg besarmembutuhkan perawatan yg seringKetika HW dan SW sudah lama hampir tak berfungsi

� Bagaimana?Sistem bisa di restrukturisasi dan didokumentasi ulanguntuk membuat menjadi mudah dalam perawatan

� Software Re-engineering (lanjutan)� Mengapa?

� Mengurangi resikoSW yang baru dibangun membawa resiko ygtinggi

� Mengurangi biaya

REUSE BASED (2)

� Mengurangi biayaBiaya untuk re-engineering sering lebih kecildibanding membangun SW baru.

REUSE BASED (3)

B. Reverse Engineering� Analisis SW kembali dalam tahap pemahaman dlm desain dan

spesifikasinya� Bisa sebagian proses re-engineering atau sebagian spesifikasi

sistem untuk diimplementasi ulang� Membangun database dan bangkitkan program informasi dari

proses ini

REUSE BASED (3)

proses ini� Mengapa?

� Kode aslinya telah dalam keterbatasan dimana sudah terlalulama, misal kebutuhan memori, kinerja, dll

� Perawatan terbentur pada struktur dan program yang rusaksehingga membutuhkan kerja yg sangat keras

� Program secara otomatis distrukturisasi ulang untukmenghilangkan beberapa bagian yang tidak beres dalamkondisi yang sangat kompleks.

Pertemuan 3

Manajemen ProyekPerangkat Lunak

Proses Dalam Manajemen PL

Manajemen proyek merupakan lapisan pertama dalam prosesrekayasa perangkat lunak skala besar. Untuk menuju padaproyek yang berhasil, perlu dimengerti tentang :

� Lingkup pekerjaan

� Resiko yang dapat ditimbulkan� Resiko yang dapat ditimbulkan

� Sumber-sumber yang diperlukan

� Tugas yang harus dilaksanakan

� Patokan yang harus diikuti

� Usaha atau biaya yang dikeluarkan

� Dan Penjadwalan

Untuk mengestimasi biaya, pembagian tugas, dan

penjadwalan, sebelum sebuah proyek direncanakan :

Langkah Awal dalam Manajemen Perangkat Lunak

�Memastikan tujuan dan ruang lingkup

�Memperhatikan alternatif-alternatif solusi

�Identifikasi batasan teknik dan manajerial

Fokus Manajemen ProyekManajemen proyek terfokus pada 4P, yaitu :1. People

Elemen terpenting dalam keberhasilan suatu proyek2. Product

Perangkat lunak yang dihasilkanPerangkat lunak yang dihasilkan3. Process

Sekelompok aktivitas kerangka kerja dalammerekayasa perangkat lunak

4. ProjectSeluruh proses yang dibutuhkan untuk menghasilkansuatu produk

Faktor-faktor yang mempengaruhi hasil akhir proyekPerangkat Lunak

� Ukuran (size)

� Batas waktu pengiriman (Delivery Deadline)

� Pembiayaan dan anggaran (Budgets & Costs)

� Bidang aplikasi (Application Domain)� Bidang aplikasi (Application Domain)

� Implementasi Teknologi (Technology Can BeImplemented)

� Batasan-batasan sistem (System Constrains)

� Kebutuhan pengguna (User Requirements)

� Sumber daya yang tersedia (Available Resource)

Permasalahan Dalam Manajemen Proyek

� Bagaimana kualitas produk yang akan dihasilkan

� Perkiraan / beban resiko yang timbul

� Ukuran perangkat lunak

� Estimasi / perkiraaan dana� Estimasi / perkiraaan dana

� Penjadwalan proyek

� Komunikasi dengan pelanggan

� Tim perancang

� Sumber daya lainnya

� Proses monitoring proyek

Fokus Dalam RPL� Analisa Resiko

� Estimasi Biaya

� Penjadwalan

� Manajemen proyek

� Pengecekan Kualitas hasil terkait dengan kualitas yangdiinginkan bersama

� Manajemen Sumber Daya Manusia

Pengukuran dan satuan ukuran akan membantu untuk

mengerti proses-proses dalam pengembangan dan

produk itu sendiri. Proses dan produk diukur usaha

Pengukuran Perangkat Lunak

produk itu sendiri. Proses dan produk diukur usaha

untuk meningkatkan kualitasnya.

1. Pengukuran Langsung

Terkait dengan biaya dan usaha yang diaplikasikan,misalnyayang menyangkut deretan kode program,kecepatan eksekusi, ukuran memori yang dibutuhkandan cacat pada produk, yang dilaporkan pada sejumlah

Pengukuran Perangkat Lunak (2)

dan cacat pada produk, yang dilaporkan pada sejumlahperiode waktu

2. Pengukuran tidak Langsung

Terkait dengan fungsionalitas, kualitas, kompleksitas,efisiensi, reabilitas, kemampuan pemeliharaan dan lain-lain

Mengapa perangkat Lunak Harus Diukur??

1. Untuk mengetahui karakteristik Perangkat Lunak

2. Proses evaluasi Perangkat Lunak

3. Prediksi kebutuhan Perangkat Lunak


3. Prediksi kebutuhan Perangkat Lunak

4. Pengembangan Perangkat Lunak

Kualitas Pengukuran Perangkat Lunak :� Correctness

Sesuai dengan spesifikasi yang diinginkan� Maintability


Kemudahan pemeliharaan dan stabil� Integrity

Daya tahan terhadap serangan dari luar sistem� Usability

Kemudahan dalam penggunaan (user-friendly)

EstimasiDalam aktifitas utama proyek yaitu perencanaan,dilakukan:

� Sumber daya manusia (ukuran orang/bulan)

� Jangka waktu kronologis (Ukuran waktu kalender)� Jangka waktu kronologis (Ukuran waktu kalender)

� Biaya (Ukuran uang Rp)

Estimasi (2)A. Tujuan Perencanaan Anggaran Proyek� Untuk menjalankan apa yang telah ditentukan dalam

tahap planning

� Memberikan arah/dukungan financial untuk membiayaiproyek

� Untuk mengontrol dan mendokumentasikan� Untuk mengontrol dan mendokumentasikanpembiayaan proyek

B. Metode Perencanaan Anggaran� Metode perkiraan (intuisi) pimpinan dan tim

� Taksiran standar

� TCA(Traditional Cost Accounting)

� ABC (Activity Based Costing)

Estimasi (3)Beberapa hal yang terkait dengan metode ABC :

� Konsistensi lebih akurat dibandingkan denganmetode TCA

� Terkonsentrasi pada biaya tidak langsung(tambahan)(tambahan)

� Biaya selalu berhubungan dengan aktifitas� Aktifitas selalu menggunakan sumber daya� Mengkonversi biaya langsung menjadi tidak langsung

� Analisis resiko merupakan serangkaian langkah untuk

menyiasati resiko

� Analisis resiko sangat penting dalam manajemen

Analisis Resiko

proyek perangkat lunak. Beberapa hal yang harus

diperhatikan berkaitan dengan resiko adalah: Masa

yang akan datang, Perubahan, Pilihan.

� Identifikasi resikoMelihat semua resiko sesuai dengan kategori(secaramakro).

� Perkiraan resikoMemperhitungkan lebih lanjut estimasi resiko.

Menyiasati Resiko

Memperhitungkan lebih lanjut estimasi resiko.� Proyeksi resiko

Disebut juga estimasi resiko, adalah usaha untukmengukur setiap resiko.

� Strategi manajemen resiko� Putusan (Resolution) resiko� Pemantauan resiko

Pengendalian ResikoStrategi Penanganan Resiko1. Manajemen Resiko Reaktif

� Tim proyek beraksi pada resiko � merekamenjumpainya

� Pelonggaran � rencana penambahan resourceantisipasi, misalnya kebakaranantisipasi, misalnya kebakaran

� Perbaikan pada kesalahan, sumber daya yangditemukan & diterapkan ketika resiko sudahmenyerang

� Manejemen krisis � kesalahan tidak dapat diresponoleh sumber daya & menjadi ancaman bagikeberlangsungan proyek

2. Manajemen Resiko Proaktif� Kinerja analisis resiko secara formal� Koreksi terorganisasi pada penyebab resiko� Pengujian sumber resiko yang diantaranya adalah

perangkat lunak

Pengendalian Resiko (2)

perangkat lunak� Pengembangan kemampuan untuk mengatur

perubahan

Perencanaan Proyek� Memahami masalah yang akan di hadapi

� Menentukan cara-cara yang tepat untuk mendapatkansolusi yang tepat

� Pengoptimalan efisiensi dan keuntungan proyek

� Memerlukan dokumen kebutuhan yang akan digunakan� Memerlukan dokumen kebutuhan yang akan digunakanuntuk pengambilan keputusan menerimaproyek/menolaknya. Jika menerima maka langkahselanjutnya adalah membuat proposal

Segitiga proyek (Proyek Triangle)1. Time

� Penjadwalan tugas, penentuan durasi,ketergantungan tugas

Perencanaan Proyek (2)

2. Money� Anggaran Belanja, sumber daya

3. Scope� Ruang lingkup pekerjaan

� Strategi Perencanaan � memilih dan menerapkannya� Hasil tujuan� Asumsi/anggapan� Pembatasan� Area/cakupan berhubungan dengan tugas dan

pengiriman


pengiriman� Tahapan perencaan Proyek

� Penentuan area/cakupan proyek� Pendefinisian tugas-tugas, teknik/tools (WBS, project

Network Diagram)� Pendefinisian sumber daya� Penjadwalan � teknik/tools : PERT, CPM, Gantt Chart� Penentuan Anggaran

Tools dan Teknik Manajemen Proyek

� Work Breakdown Structure

� Project Network Diagram

� Critical Path Method (CPM)


� Program Evaluation and Review Technique (PERT)

� Gantt Chart

� Precedence Diagramming Method (PDM)

PenjadwalanLangkah-langkah yang dilakukan dalam penjadwalan:1. Identifikasi sekumpulan tugas2. Pastikan keterkaitan antar tugas3. Estimasi usaha untuk tiap-tiap tugas4. Tentukan pekerja dan sumber-sumber lainnya4. Tentukan pekerja dan sumber-sumber lainnya5. Buat jaringan tugas6. Buat jadwal kerja berdasarkan waktu

Penelusuran dan pengendalian dilakukan

setelah ada penjadwalan yang pasti, yaitu

memeriksa apakah tugas telah dilaksanakan

Penelusuran dan Pengendalian

memeriksa apakah tugas telah dilaksanakan

sesuai dengan jadwal.

� Indikasi kualitas produk

� Perkiraan produktivitas orang-orang yangmenghasilkan produk

� Perkiraan manfaat dari penerapan metode dantools

Tujuan Pengukuran Perangkat Lunak

tools

� Membentuk dasar dari estimasi

� Menegaskan (Justify) permintaan tools baru danpelatihan

� Kualitas perangkat lunak dihitung pada saat prosesrekayasa perangkat lunak ataupun setelahdiserahkan kepada pemakai.

� Satuan ukuran kualitas perangkat lunak pada saatproses rekayasa :

Ukuran Kualitas Perangkat Lunak

proses rekayasa :

1. Kompleksitas program

2. Modularitas yang efektif

3. Besarnya program

Penyebab Kegagalan (PL)Penyebab kegagalan sebuah proyek PL :� Batas waktu pengerjaan proyek yang tidak realistis� Perubahan keinginan pelanggan� Meremehkan pekerjaan� Munculnya resiko yang dapat diperkirakan dan resiko� Munculnya resiko yang dapat diperkirakan dan resiko

yang diluar perkiraan� Kesulitan secara teknis� Kesalahpahaman antara anggota tim proyek� Kesalahan dalam manajemen proyek

Komponen Dalam Proyek PL� Manager Senior

Menentukan isu-isu bisnis yang memiliki pengaruhpenting dalam proyek

� Manager (Teknis) Proyek

Merencanakan, memotivasi, mengorganisir danmengontrol proyek sebuah produk / aplikasi

� Pelaksana

Yang menyampaikan keterampilan teknik yangdiperlukan untuk merekayasa sebuah produk / aplikasi

� Pelanggan

Menentukan jenis kebutuhan akan perangkat lunakyang akan direkayasa

� Pemakai Akhir (end-user)

Komponen Dalam Proyek PL (2)

� Pemakai Akhir (end-user)

Yang berinteraksi dengan perangkat lunak bilaperangkat lunak telah dipublikasikan (release) untukdigunakan


Faktor yang harus dipertimbangkan dalam menyeleksi timpelaksana proyek

1. Tingkat kesulitan dari masalah yang akan dikerjakan

2. Ukuran program yang dihasilkan yang terkait dengan2. Ukuran program yang dihasilkan yang terkait denganjumlah fungsi yang digunakan

3. Waktu yang dibutuhkan oleh tim untuk bekerja secarabersama-sama

4. Tingkatan dimana masalah dapat dimodularisasi /dibuat dalam bentuk modul

5. Kualitas yang diperlukan serta keandalan sistem yangdibangun

6. Kepastian tanggal penyampaian ke pelanggan

7. Memiliki kemampuan sosialisasi (komunikasi) yang


dibutuhkan dalam proyek

Definisi Masalah dalam RPL1. Menetapkan Ruang Lingkup Permasalahan :� Konteks

Bagaimana software yang akan dibangun nantinya dapatmemenuhi kebutuhan sistem serta batasan yangditentukan oleh sistemditentukan oleh sistem

� Tujuan InformasiMenentukan objek data yang dihasilkan sebagai outputdan object data yang diperlukan sebagai input

� Fungsi dan Unjuk KerjaMenentukan fungsi yang akan dilakukan untukmentransformasi input data menjadi output serta ciri kerjakhusus yang akan ditekankan

2. Dekomposisi masalahMenetapkan pembagian fungsi / aktivitas kerja pada 2area utama, yaitu ;

� Fungsionalitas yang harus disampaikan� Proses yang akan dipakai untuk menyampaikannya

Definisi Masalah dalam RPL (2)

� Proses yang akan dipakai untuk menyampaikannya

ARTIFACT UML

Actor A

Use Case 1

Use Case 2

Actor B

9: sortByName ( )

GrpFile

read( )open( )create( )fillFile( )

rep

Repository

name : char * = 0

readDoc( )readFile( )

(from Persistence)

FileMgr

fetchDoc( )sortByName( )

DocumentList

add( )delete( )

Document

name : intdocid : intnumField : int

get( )open( )close( )read( )sortFileList( )create( )fillDocument( )

fList

1

FileList

add( )delete( )

1

File

read( )

read() fill the code..

UI

MFC

RogueWave

DocumentApp

Persistence Window95

Windows95

Windows95

ºÐ»ê È¯ °æÀÇ ÇÏµå¿þ¾î¹× ³×Æ®¿÷À¸·ÎÀÇ Á¤º¸ ½Ã½ºÅÛ ¿¬°á ¸ðµ¨ - À©µµ¿ì 95 : Å¬¶óÀÌ¾ðÆ® - À©µµ¿ì NT: ÀÀ¿ë¼-¹ö - À¯ ´Ð½º ¸Ó½Å: ÀÀ¿ë ¼-¹ö ¹× µ¥ÀÌÅ¸ ¼-¹ö, Åë½Å ¼-¹ö - IBM ¸ÞÀÎÇÁ·¹ÀÓ: µ¥ÀÌÅ¸ ¼-¹ö, Åë½Å ¼-¹ö

Repository DocumentList

Customernameaddr

withdraw()fetch()send()

receive()

<<entity>>

Domain Expert

Openning

Writing

ReadingClosing

add file [ numberOffile==MAX ] / flag OFF

add file

close file

close file

Use Case 3

Use-Case Diagram

Class Diagram State Diagram

Deployment DiagramClass

user : »ç¿ëÀÚ

mainWnd : MainWnd

fileMgr : FileMgr

repository : Repositorydocument : Document

gFile : GrpFile

L1: Doc view request ( )

2: fetchDoc( )

5: readDoc ( )

7: readFile ( )

3: create ( )

6: fillDocument ( )

4: create ( )

8: fillFile ( )

global

¹®¼-°ü¸® Å¬¶óÀÌ¾ðÆ®.EXE

WindowsNT

¹®¼-°ü¸® ¿£Áø.EXE

WindowsNT

Solaris

ÀÀ¿ë¼-¹ö.EXE

AlphaUNIX

IBM Mainframe

µ¥ÀÌÅ¸º£ÀÌ½º¼-¹ö

¹®¼-°ü¸® ¾ÖÇÃ¸´

Document

FileManager

GraphicFileFile FileList

user

mainWnd fileMgr : FileMgr

repositorydocument : Document

gFile

1: Doc view request ( )

2: fetchDoc( )

3: create ( )

4: create ( )

5: readDoc ( )

6: fillDocument ( )

7: readFile ( )

8: fillFile ( )

9: sortByName ( )

Æ¯Á¤¹®¼-¿¡ ´ëÇÑ º¸±â̧ ¦ »ç¿ëÀÚ°¡ ¿äÃ»ÇÑ´Ù.

È-ÀÏ°ü̧ ®ÀÚ´Â ÀÐ¾î¿Â ¹®¼-ÀÇ Á¤º¸¸¦ ÇØ´ç ¹®¼- °́Ã¼¿¡ ¼³Á¤À» ¿äÃ»ÇÑ´Ù.

È-¸é °́Ã¼´Â ÀÐ¾îµéÀÎ °́Ã¼µé¿¡ ´ëÇØ ÀÌ¸§º°·Î Á¤·ÄÀ» ½ÃÄÑ È-¸é¿¡ º¸¿©ÁØ´Ù.

Forward Engineering(Code Generation)and

Reverse Engineering

Executable System

User InterfaceDefinition

Source Code edit, compile, debug, link

Collaboration Diagram

Sequence Diagram

Component Diagram

Package Diagram

DIAGRAM-DIAGRAM DI UML

Use CaseDiagramsUse Case

DiagramsUse CaseDiagrams

StateDiagramsState

DiagramsObjectDiagrams

Use CaseDiagramsUse Case

DiagramsActivityDiagrams

StateDiagramsState

DiagramsClassDiagrams

DeploymentDiagram

ScenarioDiagramsScenario

DiagramsSequenceDiagrams

StateDiagramsState

DiagramsStateDiagrams

ComponentDiagramsComponent

DiagramsComponentDiagrams

Model

ScenarioDiagramsScenario

DiagramsCollaborationDiagrams

USE CASE DIAGRAM

• Menggambarkan fungsionalitas yang diharapkan darisebuah sistem. Yang ditekankan adalah “apa” yangdiperbuat sistem, dan bukan “bagaimana”.

• Menggambarkan kebutuhan system dari sudutpandang user

• Mengfokuskan pada proses komputerisasi• Mengfokuskan pada proses komputerisasi(automated processes)

• Menggambarkan hubungan antara use case danactor

• Use case menggambarkan proses system (kebutuhansystem dari sudut pandang user)

• Secara umum use case adalah:– Pola perilaku system– Urutan transaksi yang berhubungan yang dilakukan

oleh satu actor• Use case diagram terdiri dari• Use case diagram terdiri dari

a. Use caseb. Actorsc. Relationshipd. System boundary boxes (optional)e. Packages (optional)

Deskripsi Use case Diagram

• Use case dibuat berdasar keperluan actor, merupakan“apa” yang dikerjakan system, bukan “bagaimana” systemmengerjakannya

• Use case diberi nama yang menyatakan apa hal yangdicapai dari hasil interaksinya dengan actor.

Use case

dicapai dari hasil interaksinya dengan actor.• Use case dinotasikan dengan gambar (horizontal ellipse)• Use case biasanya menggunakan kata kerja• Nama use case boleh terdiri dari beberapa kata dan tidak

boleh ada 2 use case yang memiliki nama yang sama

Simbol use case

ACTOR

• Actor menggambarkan orang, system atau external entitas/ stakeholder yang menyediakan atau menerima informasidari system

• Actor menggambarkan sebuah tugas/peran dan bukannyaposisi sebuah jabatanposisi sebuah jabatan

• Actor memberi input atau menerima informasi dari system• Actor biasanya menggunakan Kata benda

Simbol actor

• Tidak boleh ada komunikasi langsung antaractor

• Indikasi <<system>> untuk sebuah actor yangmerupakan sebuah system

• Adanya actor bernama “Time” yangmengindikasikan scheduled events (suatumengindikasikan scheduled events (suatukejadian yang terjadi secara periodik/bulanan)

• Letakkan actor utama anda pada pojok kiri atasdari diagram

Association

• Associations bukan menggambarkan alirandata/informasi

• Associations digunakan untuk menggambarkanbagaimana actor terlibat dalam use case

• Ada 4 jenis relasi yang bisa timbul pada use case• Ada 4 jenis relasi yang bisa timbul pada use casediagram

1. Association antara actor dan use case2. Association antara use case3. Generalization/Inheritance antara use case4. Generalization/Inheritance antara actors

Association antara actor dan use case

• Ujung panah pada association antara actor dan use casemengindikasikan siapa/apa yang meminta interaksi danbukannya mengindikasikan aliran data

• Sebaiknya gunakan Garis tanpa panah untuk associationantara actor dan use caseantara actor dan use case

• association antara actor dan use case yang menggunakanpanah terbuka untuk mengindikasikan bila actorberinteraksi secara pasif dengan system anda

Association antara use case

• <<include>> termasuk didalam use case lain(required) / (diharuskan)– Pemanggilan use case oleh use case lain, contohnya

adalah pemanggilan sebuah fungsi program– Tanda panah terbuka harus terarah ke sub use case– Gambarkan association include secara horizontal– Gambarkan association include secara horizontal

Register for courses

<<include>>

Logon validation<<include>>

Maintain curriculum

• <<extend>> perluasan dari use case lain jika kondisi atau syaratterpenuhi– Kurangi penggunaan association Extend ini, terlalu banyak

pemakaian association ini membuat diagram sulit dipahami.– Tanda panah terbuka harus terarah ke parent/base use case– Gambarkan association extend secara vertical

Association antara use case (Lanjut)

BukaRekening

<<extend>>

BukaDeposito

Nasabah

Generalization/inheritance antara use case

• Generalization/inheritance digambarkan dengan sebuah garisberpanah tertutup pada salah satu ujungnya yang menunjukkanlebih umum

• Gambarkan generalization/inheritance antara use case secaravertical dengan inheriting use case dibawah base/parent use case

• Generalization/inheritance dipakai ketika ada sebuah keadaan yang• Generalization/inheritance dipakai ketika ada sebuah keadaan yanglain sendiri/perlakuan khusus (single condition)

BukaRekening

Nasabah BukaDeposito

Generalization/inheritance antara actor

• Gambarkan generalization/inheritance antara actorssecara vertical dengan inheriting actor dibawahbase/parent use case

Use case System boundary boxes

• Digambarkan dengan kotak disekitar use case, untuk menggambarkanjangkauan system anda (scope of of your system).

• Biasanya digunakan apabila memberikan beberapa alternative systemyang dapat dijadikan pilihan

• System boundary boxes dalam penggunaannya optional

CLASS DIAGRAM• Class adalah sebuah spesifikasi yang jika diinstansiasi akan

menghasilkan sebuah objek dan merupakan inti daripengembangan dan desain berorientasi objek.

• Class menggambarkan keadaan (atribut/properti) suatusistem, sekaligus menawarkan layanan untuk memanipulasikeadaan tersebut (metoda/fungsi).

• Class diagram menggambarkan struktur dan deskripsi class,package dan objek beserta hubungan satu sama lain seperticontainment, pewarisan, asosiasi, dan lain-lain.containment, pewarisan, asosiasi, dan lain-lain.

• Class memiliki tiga area pokok :1.Nama, merupakan nama dari sebuah kelas2. Atribut, merupakan peroperti dari sebuah kelas. Atribut melambangkan

batas nilai yangmungkin ada pada obyek dari class

3. Operasi, adalah sesuatu yang bisa dilakukan oleh sebuah class atauyang dapat dilakukan olehclass lain terhadap sebuah class

CLASS DIAGRAM (LANJUTAN)

• Atribut dan metoda dapat memiliki salah satu sifat berikut :– Private, tidak dapat dipanggil dari luar class yang bersangkutan– Protected, hanya dapat dipanggil oleh class yang bersangkutan

dan anak-anak yang mewarisinya– Public, dapat dipanggil oleh siapa saja– Package, hanya dapat dipanggil oleh instance sebuah class

pada paket yang samapada paket yang sama

Nama Class

Atribut

Metode/operasi

HUBUNGAN ANTAR CLASS

1. Asosiasi, yaitu hubungan statis antar class. Umumnyamenggambarkan class yang memiliki atribut berupa classlain, atau class yang harus mengetahui eksistensi class lain.Panah navigability menunjukkan arah query antar class.

2. Agregasi, yaitu hubungan yang menyatakan bagian (“terdiriatas..”).

3. Pewarisan, yaitu hubungan hirarkis antar class. Class dapat3. Pewarisan, yaitu hubungan hirarkis antar class. Class dapatditurunkan dari class lain dan mewarisi semua atribut danmetoda class asalnya dan menambahkan fungsionalitasbaru, sehingga ia disebut anak dari class yang diwarisinya.Kebalikan dari pewarisan adalah generalisasi.

4. Hubungan dinamis, yaitu rangkaian pesan (message) yangdi-passing dari satu class kepada class lain. Hubungandinamis dapat digambarkan dengan menggunakansequence diagram yang akan dijelaskan kemudian.

CONTOH CLASS DIAGRAM

MULTIPLICITY

1..*

0..*

1

*

• Unspecified• Exactly one• Zero or more (many, unlimited)

• One or more

2..4

0..1

1..*• One or more• Zero or one (optional scalar role)• Specified range• Multiple, disjoint ranges 2, 4..6

Class Diagram diperoleh berdasarkan dari database

Contoh Kasus (Acknowledgments Evi Lutfi Muktar)

pelanggan_reg

no int(5)nomor_pelanggan varchar(12)nama_lengkap varchar(20)username varchar(13)password varchar(13)email varchar(30)

cari()simpan()batal()

i_01

nomor_agenda int(5)tgl_agenda varchar(15)nomor_pelanggan varchar(12)nama pelanggan varchar(20)alamat_pelanggan varchar (30)no_ktp varchar(19)no_telpon varchar(13)tarif_lama varchar(2)daya_lama varchar(6)tarif_baru varchar(2)daya_baru varchar(6)peruntukan varchar(20)gardu varchar(20)status varchar(1)

simpan()batal()

11 11

user

id_user varchar(50)password varchar(50)nama_lengkap varchar(100)email varchar(100)bagian varchar(100)referensi varchar(100)level varchar(50)

1n 1n

master_tarif

nomor int(5)peruntukan varchar(10)tarif varchar(2)daya varchar(10)bp int(10)ujl int(10)materai int(10)

kwitansi

nomor_kwitansi int(5)tgl_kwitansi varchar(15)nomor_agenda int(5)nomor_pelanggan varchar(12)bp int(10)ujl int(10)materai int(10)total int(10)status int(1)userid varchar(10)

simpan()batal()tambahkwitansi()cari()

n1 n1

n

n

n

n

perintah_kerja

nomor_pk int(5)tgl_pk varhcar(15)no_kwitansi int(5)

1

1

1

1keluhan_pelanggan

id int(5)nomor_pelanggan varchar(12)nama_pelanggan varchar(20)email varchar(100)keluhan textkode_security varchar(6)

Contoh Kasus (Acknowledgments Toeko triyanto)

no_kwitansi int(5)tgl_kwitansi varchar(15)status int(1)

cari()

mutasi

nomor_mutasi int(5)tgl_mutasi varchar(15)nomor_pk int(5)tgl_pk varchar(15)status int(1)

cari()

1

1

1

1

master_status

nomor_status int(1)keterangan varchar(15)

1

1

1

1

kode_security varchar(6)

simpan()batal()

tunggakan

nomor_pelanggan varchar(20)tanggal_rekening varchar(15)rupiah_ptl int(15)tagihan_lain_lain int(15)ppn int(12)ppj int(15)materai int(7)total_tagihan int(15)tanggal_bayar varchar(15)

modul

id_modul int(5)nama_modul varchar(50)link varchar(100)static_content textgambar varchar(100)publish enum('Y','N')status enum('user','admin','umum')aktif enum('Y','N')urutan int(5)

simpan()batal()

master_pelanggan

nomor_pelanggan varchar(12)nama_pelanggan varchar(20)penunjukan_alamat varchar (2)alamat_pelanggan varchar(18)nomor_bangunan varchar(3)nomor_rt int(3)nomor_rw int(2)golongan_tarif varchar(3)daya int(6)nomor_meter varchar(6)nomor_ktp varchar(20)telpon varchar(13)gardu varchar(20)

11

11

n

1

n

1

n1

n1

n

n

n

n

Statechart Statechart Diagram.

• Statechart diagram, atau yang biasa juga disebut statediagram digunakan untuk mendokumentasikan beragamkondisi/keadaan yang bisa terjadi terhadap sebuah class dankegiatan apa saja yang dapat merubah kondisi/keadaantersebut. Contohnya sebuah televisi yang dapat beradadalam kondisi menyala atau mati, jika tombol “power” ditekanmaka televisi akan menyala, begitu juga sebaliknya akanmaka televisi akan menyala, begitu juga sebaliknya akanmati jika tombol “power” ditekan kembali. Maka disini kitamempunyai sebuah kelas yaitu televisi, 2 state yaitu menyaladan mati dan 2 transition yaitu menyalakan TV danmematikan TV. Tidak seperti diagram-diagram behaviourallainnya yang memodelkan interaksi diantara beberapa class,state diagram justru biasanya hanya memodelkan transisiyang terjadi hanya pada sebuah class. Berikut adalah notasistate diagram :

State Notasi State menggambarkan kondisi sebuahentitas, dan digambarkan dengan segiempat yang pinggirnya tumpul dengan nama state didalamnya State1

Transition Sebuah Transition menggambarkan sebuahperubahan kondisi objek yang disebabkan oleh sebuah event. Transition digambarkan dengan sebuah anak panah dengan nama event yang ditulis diatasnya, dibawahnya atau sepanjang

anak panah tersebut.

Transition

sebuah kondisi awal sebuah

State1

Initial State sebuah kondisi awal sebuahobject sebelum ada perubahan keadaan. InitialState digambarkan dengan sebuah lingkaransolid. Hanya satu Initial State yang diizinkandalam sebuah diagram

Final State menggambarkan ketika objek berhentimemberi respon terhadap sebuah event. FinalState digambarkan dengan lingkaran soliddidalam sebuah lingkaran kosong.

• Statechart diagram menggambarkan transisi dan perubahankeadaan (dari satu state ke state lainnya)

• suatu objek pada sistem sebagai akibat dari stimuli yangditerima. Pada umumnya statechart

• diagram menggambarkan class tertentu (satu class dapatmemiliki lebih dari satu statechart

• diagram).• Dalam UML, state digambarkan berbentuk segiempat dengan

sudut membulat dan memiliki nama• Dalam UML, state digambarkan berbentuk segiempat dengan

sudut membulat dan memiliki nama• sesuai kondisinya saat itu. Transisi antar state umumnya

memiliki kondisi guard yang merupakan• syarat terjadinya transisi yang bersangkutan, dituliskan dalam

kurung siku. Action yang dilakukan• sebagai akibat dari event tertentu dituliskan dengan diawali garis

miring.• Titik awal dan akhir digambarkan berbentuk lingkaran berwarna

penuh dan berwarna setengah.• Contoh statechart diagram :

State Machine Diagram (Statechart diagram in versi 1.x)

• Untuk memodelkan behavior/methode (lifecycle) sebuah kelas atau object• Memperlihatkan urutan kejadian sesaat (state) yang dilalui sebuah object,

transisi dari sebuah state ke state lainnya

State Machine Diagram (Statechart diagram in versi 1.x)Sebuah state machine diagram mempunyai :• state (kejadian sesaat) are represented by the values of attributes of an object

– State digambarkan dengan bentukData Kosong

atau

– “Black Hole” statesis state has transitions into it but none out

– Miracle statesis state has transitions out of it but none into it

• initial state / creation state dengan tandaUntuk memulai sebuah state machine diagram(in western culture people read from left to right, top to bottom, starting in thetop-left corner)

• Final state dengan tandaUntuk mengakhiri sebuah state machine diagramLetakkan pada pojok kanan bawah(in western culture people read from left toright, top to bottom, starting in the top-left corner)

• Simple StateSebuah State yang tidak mempunyai Sub States/region/submachines


• Submachine State– Sejenis composite state

State 2

State 1

State 3

• Composite State– Kumpulan dari

beberapa states yang setidaknya dalam sebuah region

– Orthogonal State, jenis composite state lebih dari 1 region

– Digunakan untuk mendukung konsep encapsulation

– Sebuah state tidak boleh mempunyai region dan submachine secara bersamaan

– Nama state mempunyai sintaks : nama submachine state : referenced state machine

– Sejenis composite state yang isinya didefinisikan oleh state machine lain

– State Machine yang berisi submachine state disebut “Containing state machine”

– Sebuah state yang dihubungkan ke state machine lainnya

– Dihubungkan ke satu/lebih entry point dan satu/lebih exit point

referenced state machine

State Machine Diagram (Statechart diagram in versi 1.x)Sub States• Sebuah state yang ada dalam sebuah region

– Direct Substate, Sub state yang tidak berisi state lain

– Indirect Substate, Sub state yang berisi state lain

Region (kelompok state)• Dipisahkan dengan garis terputus, yang setiap region boleh mempunyai

nama sebagai optional• Sebuah state tidak boleh mempunyai region dan submachine secara

bersamaanbersamaan

State terpisah menjadi 3 bagian yaitu• Activity label bisa berupa Entry, Exit atau do• Dimana Activity expression adalah penggunaan atribut

NIP Kosong

Entry/isi NIP

Exit/

Help/Tekan F1

Klik

Double klik

Nama State

Internal Activity, kegiatan yang dilakukan dalam state

sintaks : Activity label/activity expression

Internal transition


Transition• digambarkan dengan tanda anak panah• progressions from one state to another, will be triggered by an event• Transition adalah hasil dari methode yang menyebabkan perubahan state,

walaupun tidak semua methode menyebabkan perubahan state

label on transition is in the formatevent [guard][/methode list()]

• event biasa dituliskan dengan past tense• event menyebabkan sebuah object berpindah dari satu state ke state lain• event menyebabkan sebuah object berpindah dari satu state ke state lain• Guard, condition that must be true for the transition to be triggered• Guard harus konsisten dan tidak overlap

Contoh: X<0, X=0 dan X>0 konsistenX<=0 dan X>=0 tidak konsisten

• Guards harus lengkap logikanyaContoh: X<0 dan X>0 , bagaimana jika X=0 ?

• Methode dijalankan– ketika object memasuki state diindkasikan dengan methode bernama

entry( )– ketika object keluar state diindikasikan dengan methode bernama exit( )

• Methode menyebabkan perubahan di sebuah state bisa juga tidak


• Join, menggabungkanbeberapa transition menjadisebuah transition

• Fork, memecah sebuahtransition menjadi beberapatransition yang berkondisiAND (transition harusdilewati semuanya).

• Junction, Menggabungkan

• Dimungkinkan transition kesebuah state yang berisibeberapa state yangdisebut state list

State1, State1, State2State2

• Junction, Menggabungkansebuah/beberapa transitiondan memecahnya menjadisebuah/beberapa transitionyang berkondisi AND(transition harus dilewatisemuanya).Digunakan tanda lingkaranhitam kecilContoh:


• Choice, Mengkondisikan sebuah transition menjadi sebuah/beberapa transition, yang hanya dipilih salah satu transition(choice).– Digunakan lambang diamond – Operand dapat diletakkan didalam diamond atau pada transition

Contoh:

• Entry pointDilambangkan sebuah lingkarankecil yang ditaruh pada pinggiranstate(bisa juga didalam ataudiluar), dan berguna sebagaisubmachine state

• Exit pointDilambangkan sebuah lingkarankecil bersilang yang ditaruh padapinggiran state (bisa juga didalamatau diluar), dan berguna sebagaisubmachine state

State Machine Diagram (Statechart diagram in versi 1.x)• State Machine Diagram ada 2 jenis

– Behavioral State Machines• Merupakan state machine diagram umumnya• Digunakan untuk mendefinisikan perilaku sebuah object

– Protocol State Machines• Digunakan untuk penggunaan protocol pada sebuah system• Dapat didefinisikan ke spesifik Protocol State Machines atau ke

Behavioral State Machines• Didefinisikan sebagai diagram context (global overview)• Notasi yang digunakan sama dengan Behavioral State Machines

dengan penambahan kata {protocol}

• Tidak adanya internal activity seperti entry,exit,do• Transition pada Protocol State Machines harus menggunakan Protocol

Transition• Protocol Transition

– Sintaks : [pre condition] event / [post condition]– precondition atau postcondition adalah guard (Guard is condition

that must be true for the transition to be triggered)– Precondition, kondisi sebelum transition– Postcondition, kondisi setelah transition

Statechart diagram

• Statechart diagram menggambarkan transisi danperubahan keadaan (dari satu state ke state lainnya)suatu objek pada sistem sebagai akibat dari stimuli yangditerima.

• Pada umumnya statechart diagram menggambarkan classtertentu (satu class dapat memiliki lebih dari satustatechart diagram).

• Dalam UML, state digambarkan berbentuk segi empat• Dalam UML, state digambarkan berbentuk segi empatdengan sudut membulat dan memiliki nama sesuaikondisinya saat itu. Transisi antar state umumnya memilikikondisi guard yang merupakan syarat terjadinya transisiyang bersangkutan, dituliskan dalam kurung siku. Actionyang dilakukan sebagai akibat dari event tertentudituliskan dengan diawali garis miring.

• Titik awal dan akhir digambarkan berbentuk lingkaranberwarna penuh dan berwarna setengah.

Contoh State Diagram

Deployment Diagram

• Deployment/physical diagram menggambarkan detailbagaimana komponen di-deploy dalam infrastruktursistem, di mana komponen akan terletak (pada mesin,server atau piranti keras apa), bagaimana kemampuanjaringan pada lokasi tersebut, spesifikasi server, dan hal-hal lain yang bersifat fisikalhal lain yang bersifat fisikal

• Sebuah node adalah server, workstation, atau pirantikeras lain yang digunakan untuk men-deploy komponendalam lingkungan sebenarnya. Hubungan antar node(misalnya TCP/IP) dan requirement dapat jugadidefinisikan dalam diagram ini.

Component Diagram

• Component diagram menggambarkan struktur danhubungan antar komponen piranti lunak, termasukketergantungan (dependency) di antaranya.

• Komponen piranti lunak adalah modul berisi code, baikberisi source code maupun binary code, baik librarymaupun executable, baik yang muncul pada compile time,link time, maupun run time.link time, maupun run time.

• Pada umumnya komponen terbentuk dari beberapa classdan/atau package, tapi dapat juga dari komponen-komponen yang lebih kecil.

• Komponen dapat juga berupa interface, yaitu kumpulanlayanan yang disediakan sebuah komponen untukkomponen lain.

Contoh : Component Diagram

applet1.class

Demo.html applet2.class

applet1.java

applet2.javaDemo.html applet2.class

logo.gif

applet2.java

Contoh : Component & Deployment Diagram

Contoh kasus (Acknowledgments Toeko triyanto)

pengisian data

isi ulangkirim

data masukan

state chart diagram pendaftaran

pengisian data

isi ulangkirim

statechart diagram pengisian data kwitansi.

simpan

simpan

data masukan

ACTIVITY DIAGRAM

• Menggambarkan proses bisnis dan urutan aktivitas dalamsebuah proses

• Dipakai pada business modeling untuk memperlihatkanurutan aktifitas proses bisnis

• Struktur diagram ini mirip flowchart atau Data FlowDiagram pada perancangan terstrukturDiagram pada perancangan terstruktur

• Sangat bermanfaat apabila kita membuat diagram initerlebih dahulu dalam memodelkan sebuah proses untukmembantu memahami proses secara keseluruhan

• Activity diagram dibuat berdasarkan sebuah ataubeberapa use case pada use case diagram

Simbol Activity Diagram

Simbol Keterangan

Start Point

End Point

Activities

Fork (Percabangan)

Join (Penggabungan)

Decision

Swimlane

Sebuah cara untuk mengelompokkan

activity berdasarkan Actor (mengelompokkan activity dalam sebuah urutan yang sama)

Sumber : Rational rose

CONTOHACTIVITYDIAGRAM

Penarikan Uang dari Account Account

Bank Melalui ATM

CONTOH ACTIVITY DIAGRAMSupplierBagian PembelianBagian Gudang

Memberi informasi dataBarang yang akan dipesan

Menerimainformasi

BuatSPP

TerimaSPP

Kirim Barangdisertai Faktur

Terima Barangdan Faktur

BuatSPBJ

TandatanganiSPBJ

TerimaSPBJ

Konfirmasipembayaran

Melakukanpembayaran

Terimapembayaran

Terima

Kwitansi

Buat

kwitansi

Procedure Berjalan (Acknowledgments Evi Lutfi Muktar)

Proses pembuatan Daftar Data Pegawai dan Gaji pada SMPPGRI 1 Depok adalah sebagai berkut :1. Proses Absensi

Pegawai melakukan absensi harian melalui form daftarhadir pegawai. Berdasarkan form daftar hadir pegawai tersebutbagian Tata Usaha (TU) akan membuat Rekap Absen (RA)harian untuk diserahkan kepada Administrasi.harian untuk diserahkan kepada Administrasi.2. Proses Pemberian Rekap Biodata Pegawai (RBP)

Pegawai memberikan data pribadi pegawai, datapendidikan, data keluarga yang dijadikan satu menjadi datapegawai kepada bagian Tata Usaha yang kemudian diarsipkanmenjadi Rekap Biodata Pegawai (RBP). Lalu Rekap BiodataPegawai (RBP) diserahkan kepada bagian administrasi untukproses pengolahan Daftar Data Pegawai Dan Gaji (DDPG).

3. Proses Pengolahan Daftar Data Pegawai dan Gaji (DDPG)Setelah bagian administrasi menerima Rekap Biodata Pegawai

(RBP) dan Rekap Absen (RA) akan mengolah kedua data tersebut untukdibuatkan menjadi Daftar Data Pegawai dan Gaji (DDPG) yangkemudian diserahkan kepada Kepala Sekolah untuk ditanda tanganiatau di Acc.

4. Proses Pembuatan Laporan4. Proses Pembuatan LaporanDaftar Data Pegawai dan Gaji (DDPG) yang sudah diterima dan

ditanda tangani oleh Kepala Sekolah akan diserahkan kembali kepadabagian Administrasi untuk dibuatkan Laporan Data Pegawai (LDP) danLaporan Gaji Pegawai (LGP).

Setelah bagian administrasi menerima Daftar Data Pegawai danGaji yang sudah di Acc akan membuatkan Laporan Data Pegawai (LDP)dan Laporan Gaji Pegawai (LGP) yang nantinya akan diserakan kepadaKepala Sekolah.selain itu bagian Administrasi akan membuatkan slipgaji untuk diserahkan kepada pegawai.

Proses Absensi

Acivity Diagram Rekap Biodata Pegawai (RBP)

Activity Diagram Pembuatan Daftar Data pegawai dan Gaji (DDPG)

Activity Diagram Proses Laporan

(Acknowledgments Toeko triyanto)

Proses bisnis pelayanan pelanggan perubahan daya padaPT PLN adalah sebagai berikut :

•Pendaftaran perubahan dayaKonsumen datang kekantor PT PLN(Persero) dengan

membawa fotocopy KTP dan kwitansi pembayaranrekening bulan terakhir kemudian diserahkan dibagianrekening bulan terakhir kemudian diserahkan dibagianpelayanan pelanggan. Pegawai pelayanan pelanggan akanmenginput berdasarkan data dari konsumen , setelahdiinput maka akan dicetak formulir pendaftaran perubahandaya untuk kemudian ditandatangani oleh pelanggan. Saturangkap untuk pelanggan sebagai tanda bukti. Lainnyadisimpan oleh bagian pelayanan pelanggan untukditeruskan ke supervisor untuk proses persetujuan

memberikan fotocopy ktp dan rekening listrik

menerima fotocopy ktp dan rekening listrik

input pendaftaran pelanggan

cetak formulir pendaftaran

spv pelayananpelayanan pelangganpelanggan

Activity diagram pendaftaran perubahan daya

menerima formulir pendaftaran

menyetujui formulir pendaftaran

memberikan formulir pendaftaran





• Persetujuan perubahan dayaRangkap formulir pendaftaran yang disimpan oleh bagian

pelayanan pelanggan kemudian dibuatkan surat jawaban persetujuanyang kemudian ditandatangani oleh supervisor pelayanan pelanggandicetak menjadi dua rangkap, rangkap pertama diberikan kepadapelanggan , sedangkan rangkap yang kedua disimpan oleh bagianpelayanan pelangan sebagai arsip.

pelangganspv pelayananpelayanan pelanggan



membuat surat persetujuan

menyetujui surat persetujuan

memberikan surat persetujuan

menerima surat persetujuan

• Perjanjian jual beli tenaga listrikSetelah pelanggan menerima surat jawaban persetujuan dari PT.

PLN (Persero) maka sipelanggan akan datang ke kantor PT PLNuntuk menandatangani surat perjanjian jual beli tenaga listrik sesuaidengan daya listrik yang baru yang akan dipasang. Surat perjanjianjual beli tenaga listrik tersebut juga ditandatangani oleh manager.

menerima surat persetujuan

membuat surat perjanjian jual beli tenaga listrik

managerspv pelayananpelanggan

menerima surat perjanjian jual beli tenaga listrik

menyetujui surat perjanjian jual beli tenaga listrik

memberikan surat perjanjian jual beli tenaga listrik

mencetak surat perjanjian jual beli tenaga listrik






menyetujui surat perjanjian jual beli tenaga listrik


• PembayaranSetelah menandatangani surat perjanjian jual beli tenaga listrik

maka sipelanggan tinggal membayar sejumlah yang tertera padasurat perjanjian jual beli tenaga listrik ke loket pembayaranperubahan daya, pelanggan akan mendapatkan kwitansipembayaran sebagai bukti bahwa si pelanggan telah melaksanakankewajibannya.

loket PT PLNpelanggan

melakukan pembayaran

menerima bukti pembayaran

menerima pembayaran

cetak bukti pembayaran

menyetujui bukti pembayaran

memberikan bukti pembayaran

• Perintah kerjaSaaat si pelanggan membayar kewajibannya maka perintah

kerja terbit dan siap untuk di cetak, untuk diberikan kepadapelaksana sebagai perintah kerja untuk pelanksanaanpenggantian MCB pelanggan.

cetak perintah kerja

menyetujui perintah kerja

pelangganpelaksanabagian penyambungan

perintah kerja

melakukan penggantian MCB

menerima perintah kerja


melakukan penggantian MCB

memberikan perintah kerja




menyetujui perintah kerja


• Koperasi STMIK Nusa Mandiri adalah sebuah koperasiyang mengelola simpan pinjam bagi para anggotanya,berikut ini adalah kegiatan yang dilakukan oleh bagianKredit dalam menangani pemberian pinjaman bagi paraanggotanya.

• Setiap kali bagian kredit akan memberikan pinjamankepada Anggota maka Anggota diharuskan mengisiFormulir Permohonan Pinjaman yang berisi Nomor FPP,

Latihan STUDI KASUS ACTIVITY DIAGRAM

Formulir Permohonan Pinjaman yang berisi Nomor FPP,Tanggal Permohonan, Nomor Anggota, Nama Anggota,Jumlah Permohonan dan Keperluan. Yang kemudian olehBagian Kredit dicatat dan disimpan kedalam Arsip FPP.Berdasarkan Arsip FPP tersebut Bagian Kredit membuatBukti Peminjaman yang diberikan kepada Anggota yangberisi No. BP, tgl BP, Nomor Anggota, Nama Anggota,Jumlah Realisasi, Lama Angsuran, Jumlah Angsuran danBunga.

• Setiap Bulan Anggota diharuskan membayar Angsuransejumlah Angsuran yang disepakati pada saatPeminjaman yang kemudian oleh bagian Kredit dicatatdan direkam kedalam Arsip Angsuran. BerdasarkanArsip Angsuran tersebut bagian Kredit membuat BuktiAngsuran yang diberikan kepada Anggota yang berisiNo. BA, Tanggal BA, No. BP, Jumlah Angsur dan BungaNo. BA, Tanggal BA, No. BP, Jumlah Angsur dan Bunga

• Pada akhir bulan Bagian Kredit selalu membuat LaporanPeminjaman dan Laporan Angsuran yang diberikanKepada Ketua Koperasi.

Latihan Activity Diagram !

PT. Nusantara adalah sebuah perusahaan yang bergerakdibidang penjualan Tunai barang-barang elektronik. Semuatransaksi di perusahaan masih dilakukan secara manual.Berikut ini adalah kegiatan kegiatan yang dilakukan olehbagian Penjualan dalam melaksanakan transaksi penjualanBarang di dalam perusahaan.

1. Pemesanan barang1. Pemesanan barangSetiap kali Bagian penjualan akan menjual barang ia selalu

menerima surat pesanan dari pelanggan. Berdasarkan Suratpesanan tersebut bagian penjualan kemudian mencatat danmerekamnya kedalam Arsip Surat Pesanan. BerdasarkanArsip surat pesanan tersebut, bagian penjualan membuatkanFaktur dan Surat Jalan yang dikirimkan kepada Pelanggansebagai bukti bahwa barang yang dipesan sudah terealisasidan rangkapnya disimpan sebagai Arsip Faktur dan ArsipSurat Jalan.

2. Pembuatan KwitansiApabila Faktur dan Surat Jalan sudah sampai ditempat

pelanggan, maka pelanggan megirimkan Pembayaranyang kemudian oleh bagian penjualan dibuatkanKwitansi yang dibuat berdasarkan Arsip Faktur yangkemudian diserahkan kepada pelanggan sebagai buktipembayaran dan rangkapnya disimpan kedalam ArsipKwitansi

3. Pembuatan Laporan3. Pembuatan LaporanSetiap akhir bulan Bagian Penjualan selalu membuat

Laporan Penjualan berdasarkan Arsip Faktur danLaporan Pesanan berdasarkan Arsip Pesanan danLaporan Pengiriman berdasarkan Arsip Surat Jalanyang ditujukan kepada Kepala Bagian Penjualan

Diminta :• Buatlah Activity diagram dari data diatas !

Sequence Diagram

• Sequence diagram menggambarkan interaksi antar objekdi dalam dan di sekitar sistem (termasuk pengguna,display, dan sebagainya) berupa message yangdigambarkan terhadap waktu. Sequence diagram terdiriatar dimensi vertikal (waktu) dan dimensi horizontal (objek-objek yang terkait).

• Sequence diagram biasa digunakan untukmenggambarkan skenario atau rangkaian langkah-langkah yang dilakukan sebagai respons dari sebuahevent untuk menghasilkan output tertentu. Diawali dariapa yang men-trigger aktivitas tersebut, proses danperubahan apa saja yang terjadi secara internal danoutput apa yang dihasilkan.

• Diagram ini secara khusus berasosiasi dengan use case• Diagram ini secara khusus berasosiasi dengan use casediagram

• Memperlihatkan tahap demi tahap apa yang seharusnyaterjadi untuk menghasilkan sesuatu didalam use case

Simbol Sequence Diagram

Contoh Sequence Diagram

SEQUENCE DIAGRAM INPUT DATA PEGAWAI SEQUENCE DIAGRAM INPUT DATA PEGAWAI

Contoh kasus Penggajian (Acknowledgments Evi Lutfi Muktar)

SEQUENCE DIAGRAM INPUT DATA PENDIDIKANSEQUENCE DIAGRAM INPUT DATA PENDIDIKAN

SEQUENCE DIAGRAM INPUT DATA KELUARGASEQUENCE DIAGRAM INPUT DATA KELUARGA

SEQUENCE DIAGRAM ABSEN MASUKSEQUENCE DIAGRAM ABSEN MASUK

: administrator : form tambah manajemen user : control form tambah manajemen user

: pelanggan

open ( )

get username, passwordnama lengkap, email

display username, password

nama lengkap, email

Contoh kasus PLN (Acknowledgments Toeko triyanto)

simpan simpan

: pelanggan : form tambah pendaftaran : controlform tambah pendaftaran

: pelanggan1

open ( )get nomor_pelangganperuntukan, tarif, daya

display nomor_pelanggannama pelangganalamatnomor ktpnomor telpon

gardugardu

daya tarif lamadaya tarif baruperuntukan

simpansimpan

display no, agenda,tgl, id_pelanggan

nama, daya_lamadaya_baru, status,aksi

• Collaboration diagram juga menggambarkan interaksiantar objek seperti sequence diagram, tetapi lebihmenekankan pada peran masing-masing objek danbukan pada waktu Penyampaian message.

• Setiap message memiliki sequence number, di manamessage dari level tertinggi memiliki nomor 1. Messagesmessage dari level tertinggi memiliki nomor 1. Messagesdari level yang sama memiliki prefiks yang sama.

Contoh Collaboration Diagram

Berikut adalah sebuah contoh collaboration diagram yang mengilustrasikan sebuahsistem telepon genggam (handphone) :

Collaboration Diagram (Acknowledgments Toeko triyanto)

: index\home : pengunjung

: info

: register

: login

: cari

: simpan

: batal

: login1

: batal

: index\home

: pendaftaran

: manajemen kontrol

: tambah data

: cetak

: simpan

: batal

: logout

: index\home : login1

: manajemen user

: edit

: hapus

: batal

: tambah user

: simpan

: update

: batal

: manajemen modul

: tambah modul

: edit

: hapus

: simpan

: batal

: update

: batal : profile

: browse

: update

: tambah data : pendaftaran

: cetak : cari

: simpan

: batal

: cetak dokumen

: cari

: cetak

: kwitansi1

: tambah kwitansi

: cetak

: cari

: simpan

: batal : cari

: member

: admin : login

: batal

: cetak

: perintah kerja1

: cari

: cetak

: mutasi1

: batal

: manajemen kontrol1

: cari

: cari

: peremajaan : data pelanggan1

: cari : informasi tagihan1

: cari

: guestbook1 : tambah guestbook

: batal

: simpan

: edit : hapus

: batal : simpan

: user : index\home

: cetak dokumen

: cari : cetak

: kwitansi1

: tambah kwitansi

: cetak

: cari

: simpan

: batal

: perintah kerja1

: cari

: cetak

: batal

: cari

: peremajaan

: mutasi1 : data pelanggan1

: cari

: informasi tagihan1

: cari

: guestbook1 : tambah guestbook

: batal

: simpan

: edit : hapus

: batal : simpan

PERTEMUAN 6

COMPONENT DIAGRAM

� Component diagram menggambarkan struktur danhubungan antar komponen piranti lunak, termasukketergantungan (dependency) di antaranya.

� Komponen piranti lunak adalah modul berisi code, baikberisi source code maupun binary code, baik librarymaupun executable, baik yang muncul pada compiletime, link time, maupun run time.

� Umumnya komponen terbentuk dari beberapa class

Component Diagram

� Umumnya komponen terbentuk dari beberapa classdan/atau package, tapi dapat juga dari komponen-komponen yang lebih kecil.

� Komponen dapat juga berupa interface, yaitu kumpulanlayanan yang disediakan sebuah komponen untukkomponen lain.

Contoh component diagram:

Component Diagram• Menggambarkan alokasi semua class dan object kedalam komponen dalam

desain fisik system software, termasuk pengaturan dan kebergantungan antar komponen software

• Component dapat terdiri dari– logical component, seperti business component, process component, dll– Physical component (software arsitektur) , seperti Com+, dot

NET,CORBA, dll • Component digambarkan

dengan bentuk pada UML versi 1.*:

• Pada UML versi 2 digambarkan dengan bentuk

atau atau atau

• Stereotypes yang dapat digambarkan pada bentuk component<<application>>,kumpulan aplikasi system <<executable>>,component yang jalan di client<<file>>, data file

<<infrastructure>>, technical component didalam system<<source code>>, source file<<table>>, table data dalam sebuah database

<<UI>>, User interface (screen, pages, report)dll

<<database>><<document>><<library>><<web service>><<XML DTD>>

Component DiagramDependencies• dimodelkan dengan garis terputus dengan panah terbuka • gambarkan dependencies dari kiri ke kanan

Contoh:<<ASP>> Source Code bergantung pada <<database>> MySQL

• Dimungkinkan sebuah component dependencies pada interfaces component lainnyaContoh:

InheritanceInheritance• inheriting/child component diletakkan dibawah parent component, dengan

arah panah menuju ke parent component• dimodelkan dengan garis dengan panah tertutup Contoh:

Penjualan

<<application>>

Menu Utama

<<UI>>

Pembelian

<<application>>

Interfaces - Component Diagram• Interfaces adalah kumpulan >=1 methode dan >=0 attribute yang dapat

dipakai pada class tanpa menjadi behavior suatu class. • Jenis interface ada 2 macam yaitu :

– Provide, digambarkan dengan bentuk lollipopPada UML 1.* bisa juga digambarkan dengan garis terputus dengan panah tertutup

– Required, digambarkan dengan bentuk socket• Penggambaran

interfaces dapat juga dilakukan dengan menambah bagian component seperti contoh dibawah ini contoh dibawah ini

Bentuk grafik

Component Diagram

port• adalah bentuk object yang menjelaskan interaksi antara object dan

lingkungannya• digambarkan sebagai kotak kecil di pinggiran componentAssembly connector• Penghubung antara

2/lebih component dimana sebuah/beberapa component provides interfaces dan component lain required component lain required interfaces

• Digambarkan dengan gabungan bentuk interfacescontoh:

Component Diagram (Acknowledgments Toeko triyanto)

Kirim

Simpan database server

Browsing

Isi data

Deployment Diagram

� Deployment/physical diagram menggambarkan detailbagaimana komponen di-deploy dalam infrastruktur sistem, dimana komponen akan terletak (pada mesin, server atau pirantikeras apa), bagaimana kemampuan jaringan pada lokasitersebut, spesifikasi server, dan hal-hal lain yang bersifatfisikal

� Sebuah node adalah server, workstation, atau piranti keraslain yang digunakan untuk men-deploy komponen dalam

Deployment Diagram

lain yang digunakan untuk men-deploy komponen dalamlingkungan sebenarnya. Hubungan antar node (misalnyaTCP/IP) dan requirement dapat juga didefinisikan dalamdiagram ini

� Deployment diagram digunakan untuk melayani pemodelanhardware yang digunakan dalam implementasi sistem danasosiasinya antara komponen-komponen tersebut. Elemenyang digunakan dalam deployment diagram adalah nodes(ditunjukkan sebagai sebuah cube), komponen (ditunjukkansebagai sebuah kotak bujursangkar) dan juga asosiasi.

• Deployment diagram ini menunjukkan hardware yang digunakan padajaringan kantor yang kecil. Application server (node) terhubung dengandatabase server (node) dan database client (component) sudahterinstall dalam application server. Workstation juga terhubung(association) dengan application server dan juga ke printer.

Deployment Diagram• Menggambarkan arsitektur system• Pemetaan software(component pada component diagram) yang jalan di

sebuah hardware (node pada deployment diagram)• Software component tidak selalu menggambarkan setiap software

component yang ada pada sebuah Komputer(system operasi/MicrosoftOffice, dll), akan tetapi software component tersebut akan digambarkanketika ada hubungan dengan pengimplementasian sebuah system

• Menggambarkan bagaimana s/w dan h/w bekerja sama• Menggambarkan topologi jaringan• Artifact

– Spesifikasi dari bentuk physic informasi yang digunakan atau dihasilkan– Contoh : source file, script, executable file, table di database, document– Contoh : source file, script, executable file, table di database, document

word/excel, e-mail, dll– Digambarkan dengan bentuk

– Dapat dihubungkan dengan component pada component diagram– Hanya digambarkan dalam sebuah node– perhatikan potongan program dibawah ini yang sesuai dengan artifact yang ada:– <! order.ASp>– – – //code style sheet– <script src="tgl.js"> //javascript– </script>

Node - Deployment Diagram• Adalah hardware seperti

– computer/PDA ,lap top, handphone – peralatan komunikasi data (router,hub,switch,modem)– dll

• Digambarkan dengan bentuk kotak 3 dimensi Nama Node

• Node dapat digabungkan dengan component pada component diagram

• Node dapat digambarkan dengan bentuk visual, ataupun gabungan antara node dan visual

Association (connection) - Deployment Diagram

• Digambarkan dengan sebuah garis yang menghubungkan antara node

• Setiap association mempunyai sebuah stereotypes seperti

Stereotypes Istilah

Asychronous Hubungan asynchronous

HTTP HyperText Transport Protocol (internet protocol_

JOBC Java Database Connectivity, a Java API for database access.

ODBC Open Database Connectivity, a Microsoft API for database access.

Client Server* <<asynchronous>> 1* <<asynchronous>> 1

association dimungkinkan mempunyai multiplicity (0..1, 1..*, dll)

RMI Remote Method Invocation, a Java communication protocol.

RPC Communication via remote procedure calls

Synchronous Komunikasi synchronous

Web Services Komunikasi melalui Web Services protocols seperti as SOAP and UDDI

Ethernet Ethernet Card

Dependencies - Deployment Diagram• Digambarkan dengan garis terputus yang berpanah terbuka• deploy

Sebuah garis terputus dengan ujung panah terbuka yang tertuju ke node dengan sebuah stereotypes <<deploy>> untuk menggambarkan software yang terdapat pada sebuah hardware

faktur.asp dependencies terhadap order.asp

• dimungkinkan sebuah node memiliki node yang lain

terhadap order.asp

• cara diatas dapat digambarkan dengan memasukkan artifact/software ke dalam node/hardware

atau

Manifest - Deployment Diagram• bentuk fisik dari artifact• digambarkan dengan sebuah garis terputus dengan ujung panah terbuka

yang tertuju ke component dengan sebuah stereotypes <<manifest>>

Interaction Overview Diagram• Sebuah jenis activity

Diagram yang memperlihatkan alur control dalam system atau business process.

• Setiap node/activity didalam diagram mewakili interaction diagram yang lain

• Sd = sequence diagram

sd

diagram yang lain• Interaction Overview

Diagram menggunakan notasi yang dipakai pada Activity diagram dan Sequence Diagram

• Interaction, dilambangkan dengan gambar dibawah ini

Interaction Overview DiagramContoh

• Sequence diagram• Interaction overview diagram

Timing Diagram• Memperlihatkan interaksi ketika tujuan utama diagram adalah waktu• Menggambarkan perubahan dalam state atau kondisi dari pengelompokkan

instance atau tugas berlebihan• Biasanya dipakai untuk memperlihatkan perubahan dalam state object

berlebihan dalam merespon ke external events• Dipakai untuk memperlihatkan perilaku dari sebuah/beberapa object melalui

periode waktu• Ada 2 jenis

Timing diagram yaitu– Concise/

simple notation

Dipakai untuk mengeksplorasi sebuah/beberapa object melalui periode waktuketerangan gambar :� object � :seminar� states � proposed, scheduled, enrolling students,

Being Taught, Final Exams, Closed� Lifeline �

� Timing Constrant� | {Nov 1 .. Des 31} | {jan 1 .. July 31}

– Robust notationTiming Diagram

ObjectObject

LifelineLifeline

StateState/condition/condition

LifelineLifeline

MessagMessagee

• Menggambarkan stuktur internal dari pengelompokkan (class, component, use case), termasuk hubungan pengelompokkan ke bagian lain dari system

• Collaboration– Mendefinisikan struktur dari kerjasama element/role– Ditampilkan dalam bentuk elipse dengan garis terputus, yang berisi nama

collaboration– Digunakan untuk menjelaskan bagaimana system bekerja

Composite Structure Diagram

atauatau

• Collaboration occurrence– Sebuah collaboration dihubungkan ke sebuah methode atau object melalui

collaboration occurrence– Digambarkan dengan sebuah elipse dengan garis terputus yang berisi nama

occurrence (kejadian/peristiwa), titik dua dan type collaboration• Contoh: retail:sale


Keterangan gambar :• Collaboration sale menggambarkan

collaboration antara role buyer dan seller

• Collaboration brokeredsale menggambarkan collaboration diantara 3 role yaitu producer, diantara 3 role yaitu producer, broker dan consumer

• Collaboration brokeredsale terdiri dari 2 occurrence dari collaboration sale yaitu wholesale:sale dan retail:sale

• Ocucurrence wholesale mengindikasikan collaboration sale dimana producer sebagai seller dan broker adalah buyer

• Role– Digambarkan dengan kotak

dengan berisi nama Role Broker

Contoh Deploment Diagram (Acknowledgments Toeko triyanto)

Client Browser Client Browser

Client Browser

Sebuah bentuk pengelompokkan yang memungkinkan untukmengambil sebuah bentuk di UML dan mengelompokkanelemen-elemennya dalam tingkatan unit yang lebih tinggi.Kegunaan package yang paling umum adalah untukmengelompokkan class.

• Package Diagram

•Package Diagram•Package Diagram

Menggambarkan pengelompokan dari suatu class-class

guestbook

i_01

index/home

keluhan pelanggan kwitansi

master_pelanggan

perintah_kerja

tunggakan

Contoh package diagram (Acknowledgments Toeko triyanto)

index/home

master_status

Master_tarifmodul

mutasi

pelanggan_reg

user.

Entity Relationship Diagram (ERD)

ERD adalah :Model untuk menjelaskan hubungan antar data dalambasis data berdasarkan suatu persepsi bahwa real wordterdiri dari objek-object dasar yang mempunyai hubunganterdiri dari objek-object dasar yang mempunyai hubunganatau relasi antara objek-objek tersebut

TAHAP MEMBUAT ERD1. Keluarkan semua atribut yang dimiliki oleh dokumen

sumber2. Tentukan Atribut yang dapat menjadi Primary Key

jika TIDAK ADA boleh DIBUAT BARU lalu tentukan ketergantungan atribut terhadap primary key nyaketergantungan atribut terhadap primary key nya

3. Tentukan nama entitas dari kelompok atribut yang telah bergantung terhadap primary keynya.

4. Gambarkan hubungan masing-masing entitas beserta atribut – atributnya.

5. Tentukan Cardinality/tingkat hubungan dari masing-masing Entitas yang telah terhubung.

Notasi dan Penamaan Untuk Konstruksi Skema Diagram ER

No Simbol Keterangan

1. Entity TypeSuatu yang ada (secara eksplisit ada) namunkeberadaannya dapat nyata dapat virtual, sertaperbedaan antar entity harus jelas.Ex. Pegawai, DepartemenEx. Pegawai, Departemen

2. Weak entity TypeSuatu entity yang tidak punya key atribut keberadaannyatidak perlu berdiri sendiri / diluar system. Didalam weakdimungkinkan 1 weak memiliki banyak entity. Setidaknya-tidaknya memiliki 1 relasi.Ex.

Karyawan Departemen

Salary

3. AttributeKeterangan yang dimilikientity / sifat-sifat yang melekatpada entity yang perlu dicatat.Ex. Pegawai: Nopeg, Nama, Alamat, Jenis Kel, tgl. Masuk

4. Key AttributeBila didalam attribute terdapat nilai sama, maka kita perlumembuat “Key attribute” sehingga dipastikan tidak akanmembuat “Key attribute” sehingga dipastikan tidak akanterjadi nilai/record sama.Ex. Pegawai : sebagai key adalah NoPegNoPeg Nama Alamat

P01 Bella MalangP02 Bella Batu

5. Multivalued Attribute

Satu entity yang memiliki 2 attribute sama Ex. Departemen yang memiliki 2 lokasi pabrikDepartemen

Hal ini bukan berarti bias untuk orang yang

Departemen Lokasi

Hal ini bukan berarti bias untuk orang yangmempunyai 2 nama atau 2 alamat

6. Composite AttributeAttribute yang mempunyai nilai attribute lebih dari SatuEx. Nama : Nama Depan Alamat : Jalan

Nama Tengah NomerNama Belakang Kota

7. Derived Attribute

Merupakan kombinasi dari attribute-attribute dimanakeberadaannya tidak perlu disimpan.Ex. MHS Mata Kuliah

E1

8. Identifying Relationship TypeBila entity mempunyai hubungan lebih dari satuentity lain.

E1

E2

E2

9. Relationship TypeMenyatakan hubungan antar attribute sehinggaterjadi pemetaan.Ex.

Mahasiswa Mat. KulBisaAmbi

l

*

*

##

M N

Hasil Dari Relasi :One To One (1:1)One To Many (1:N) Many To Many (1:M)

*###

Domain

Range

Kodomain

� UNARY RELATIONSHIP

� BINARY RELATIONSHIP

Derajat Relationship

� BINARY RELATIONSHIP

� N-ARY RELATIONSHIP

ENTITY-RELATIONSHIP DIAGRAM

PEGAWAI JABATANPUNYA

PEGAWAI MEMPUNYAI JABATAN

PEGAWAI DIPUNYAI OLEH JABATAN

PROYEK PEGAWAIKERJA

PROYEK DIKERJAKAN OLEH PEGAWAI

PROYEK MENGERJAKAN PEGAWAI


PEGAWAI JABATANPUNYA1 1

1 1

1 1

PROYEK PEGAWAIKERJA1 M

PROYEK PEGAWAIKERJA

1 M

1 1

MHSISWA MT-KULIAHIKUTM N

1 M

M 1


PEGAWAI JABATANPUNYA1 1

NO-PEGNAMAALAMAT

KD-JABURAIANTUNJANGAN

NO-PEGKD-JAB

PROYEK PEGAWAIKERJA1 M

NIMNAMAALAMAT

KD-MATKULNM-MATKULSKS

MHSISWA MT-KULIAHIKUTM N

NIMKD-MATKULNILAI

KD-PROYNM-PROYANGGARAN

NO-PEGNAMAHONOR

KD-PROYNO-PEG


� JENIS ENTITY

PEGAWAI ABSENISI1 M

STRONG ENTITY WEAK ENTITY

PEGAWAI ABSENISI1 M

NO-PEGNAMAALAMAT

TANGGALJAM-MASUKJAM-PULANG

NO-PEG

TIDAK MEMPUNYAI KEY


PEGAWAI KERJA PROYEK

M M

1

M

NO-PEGNAMAGAPOKLAMA-KERJAJABATAN

NO-PROYNAMA-PROYBIAYA

NO-PEGNO-PROY

1

BAGIAN

PUNYA

N

BARANG

PAKAI

NO-PROYKD-BARJUMLAH

KD-BARHARGA-BARNAMA-BAR

KD-BAGNAMA-BAG

NO-PEGKD-BAG

KASUS : ANALISA SISTEM BERJALANPosedur Sistem Berjalan

Perusahaan Bina Sarana Indonesia adalah perusahaanusaha dagang yang bergerak di bidang distributorpenjualan elektronik (TV, kulkas, kipas angin, radio danlain lain), Perusahaan ini menjual barang elektronikkepada customer secara tunai dengan nilai transaksi ≥kepada customer secara tunai dengan nilai transaksi ≥Rp. 50.000.000,-(lima puluh juta rupiah). Customeradalah badan usaha atau toko pengecer yang menjualproduknya kepada pelanggan secara perorangan. Padaprosedur sistem berjalan ini, Customer pada saatmemesan barang diharuskan melampiri dokumen POterlebih dahulu, dan PO paling lama satu minggu untukdi konfirmasi pada Customer. Maka untuk lebih jelasnyaprosedur dari sistem berjalan adalah sebagai berikut:

a.Prosedur Order PenjualanSetiap costumer dapat memesan barang datanglangsung atau melalui faximile denganmenyertakan dokumen PO yang diterima olehbagian penjualan. Kemudian bagian penjualanberdasarkan PO, memeriksa pesanan barangberdasarkan PO, memeriksa pesanan barangdengan menggunakan kartu stock, apabila stockbarang ada maka di hitung nilai penjualan dandicatat kedalam faktur penjualan. Jika stockbarang tidak ada, maka di catat ke dokumenDaftar Permintaan Stock Barang (DPSB), fakturpenjualan rangkap 4 (empat), yang telah di buatdidistribusikan ke Kasir

b. Prosedur Pembayaran TunaiSetelah customer mendapat konfirmasi tentangpesanan pembelian disetujui, maka customermelakukan transaksi pembayaran melalui transfer uangke bank yang ditunjuk dengan bukti setoran.Berdasarkan bukti setoran, Kasir membuka arsippenjualan yang dicocokan dengan bukti setoran.penjualan yang dicocokan dengan bukti setoran.Apabila sesuai dengan nilai penjualan maka dibuatkankwitansi lunas, dan merekap nilai penjualanHarian/Daily Sales Report (DSR). Distribusi dokumen-dokumen berdasarkan nilai transaksi penjualan sebagaiberikut : untuk Kwitansi dan faktur penjualan di berikankepada customer. Gudang mendapat tembusanpengeluaran barang dari kasir sesuai barang yang dipesan, dan Copy faktur diberikan ke Bagian Penjualan.

c. Prosedur Pennyiapan Barang kirimGudang Setelah menerima Tembusan pengeluaranbarang, maka menyiapkan barang yang akan dikirimdengan mencatat barang keluar ke kartu gudangdan membuat dokumensurat keluar barang yang ditembuskan ke bagianPenjualan.

d. Prosedur Pengiriman BarangBagian Penjualan berdasarkan Surat keluar barang,selanjutnya membuka arsip faktur penjualan untukmencatat barang yang akan dikirim ke dokumenSurat Jalan. Dokumen surat keluar barangdidistribusikan ke Bagian Pengiriman beserta barangdan disampaikan ke Customer

e.Prosedur Pembuatan LaporanSetiap akhir periode di buat laporan penjualan bulanan,berdasarkan rekap penjualan harian dan fakturpenjualan. Laporan stock barang keluar berdasarkanKartu Stock dan Kartu Gudang. Ke-dua laporantersebut diberikan kepada Manajer Penjualan untukproses evaluasi penjualan selama satu bulan.proses evaluasi penjualan selama satu bulan.

PERTANYAAN :1. Gambarkan DAD yang terdiri dari :

- Diagram KONTEKS- Diagram NOL- Diagram DETAIL

2. Analisa beberapa permasalahan dari Prosedur SistemPenjualan

RANCANGAN SISTEM USULAN

A. Prosedur Order PenjualanSetiap Customer dapat memesan barang datanglangsung atau melalui faximile dengan menyertakandokumen PO yang diterima oleh Bagian Penjualan.Kemudian Bagian Penjualan berdasarkan PO,Kemudian Bagian Penjualan berdasarkan PO,mengecek jumlah pesanan dan status Customer denganstock barang yang berada di file barang dan statusCustomer berdasarkan file Customer. Apabila stockbarang ada maka di lakukan proses pengentriantransaksi nilai penjualan yang disimpan ke file faktur danfile Isi_faktur. Kemudian berdasarkan file faktur dan fileIsi_faktur dicetak ke dokumen faktur penjualan(4rangkap) yang dikirimkan ke Kasir.

B. Prosedur Pembayaran TunaiSetelah Customer mendapat konfirmasi tentangpesanan pembelian disetujui, maka Customermelakukan transaksi pembayaran melalui transfer uangke bank yang ditunjuk dengan bukti setoran.Berdasarkan bukti setoran, Kasir membuka transaksipembayaran dengan membuka database penjualan (filebarang, file customer, file faktur, file Isi_faktur ).barang, file customer, file faktur, file Isi_faktur ).Kemudian data pembayaran disimpan kedalam filebayar. Berdasarkan file bayar maka dilakukanpencetakan kwitansi ( dua rangkap ). Semua dokumenpenjualan didistribusikan oleh Kasir ke beberapa bagian,yaitu sebagai berikut :– Kwitansi Asli dan Faktur Penjualan Asli diberikan ke Customer.– Copy kwitansi dan Copy Faktur Penjualan di berikan ke Bagian

Akunting– Copy Faktur didistribusikan ke Bagian Penjualan, Bagian

Gudang (Tembusan Pengeluaran Barang).

C. Prosedur Jurnal PenjualanBagian Akunting melakukan proses up-date transaksijurnal penjualan berdasarkan file bayar dan file perkiraanyang disimpan ke file jurnal.

D. Prosedur Pengiriman BarangBagian Penjualan membuat dokumen Surat Jalan (SJ)Bagian Penjualan membuat dokumen Surat Jalan (SJ)dengan mengentry jumlah barang yang dijualberdasarkan database penjualan(fie barang,filecustomer, file faktur dan file Isi_faktur) yang disimpandalam file SJ dan file Isi_SJ. Dokumen SJ di berikan kebagian Pengiriman yang diantar ke Customer. DokumenSJ didistribusikan ke Gudang untuk menyiapkan barangagar dikirimkan Ke Customer.

E. Prosedur Pembuatan LaporanSetiap akhir periode di buat laporan penjualan bulanan,berdasarkan rekap penjualan harian dan fakturpenjualan. Laporan stock barang keluar berdasarkanKartu Stock dan Kartu Gudang. Ke-dua laporan tersebutdiberikan kepada Manajer Penjualan untuk prosesevaluasi penjualan selama satu bulan.evaluasi penjualan selama satu bulan.

PERTANYAAN :1. Gambarkan DAD Usulan yang terdiri dari :

- Diagram KONTEKS- Diagram NOL- Diagram DETAIL

2. Gambarkan ERD dari kasus tersebut

Latihan 1. Suatu network yang menggambarkan suatu sistem

automatic/ komputerisasi , manual dan gabungan darikeduanya dalam susunan berbentuk komponen sistemyang saling berhubungan sesuai dengan aturan mainnyaa. DFD d. entityb. proses e. jaringan c. entitas

2. Simbol relationship pada ERD biasanya menggunakanketerangan berupaa. kata benda d. kata sifatb. kata kerja e. kata perintahc. kata pengganti

3. Dibawah ini adalah pernyataan yang benar dari aturan main DFD ,kecuali…

2. Simbol relationship pada ERD biasanya menggunakan keteranganberupaa. kata benda d. kata sifatb. kata kerja e. kata perintahc. kata pengganti

a. Dlm DFD tidak boleh menghubungkan antara EXTERNALENTITY dgn EXTERNAL ENTITY secara langsung

b. Dlm DFD tidak boleh menghubungkan antara DATA STORE dgnDATA STORE secara langsung

c. Dlm DFD tidak boleh menghubungkan antara DATA STOREdgnEXTERNAL ENTITY secara langsung (atau sebaliknya)

d. Setiap PROSES harus ada DATA FLOW yg masuk dan tidakada DATA FLOW yg keluar.

e. Salah semua

3. Dibawah ini adalah pernyataan yang benar dari aturan main DFD ,kecuali…

a. Dlm DFD tidak boleh menghubungkan antara EXTERNALENTITY dgn EXTERNAL ENTITY secara langsung

b. Dlm DFD tidak boleh menghubungkan antara DATA STORE dgnDATA STORE secara langsung

c. Dlm DFD tidak boleh menghubungkan antara DATA STOREdgnEXTERNAL ENTITY secara langsung (atau sebaliknya)

4. Tahapan proses pembuatan DFD yang menggambarkan sistem secara global a. Diagram konteks d. Diagram Nolb. Diagram Detail e. diagram Top Downc. Diagram Objek

dgnEXTERNAL ENTITY secara langsung (atau sebaliknya)d. Setiap PROSES harus ada DATA FLOW yg masuk dan tidak

ada DATA FLOW yg keluar.e. Salah semua

4. Tahapan proses pembuatan DFD yang menggambarkan sistem secara global a. Diagram konteks d. Diagram Nolb. Diagram Detail e. diagram Top Downc. Diagram Objek

5. Gambar diatas adalah a. unary relationship d. binary relationshipb. N-ary relationship e. ternary relationshipc. M-ary relationship

5. Gambar diatas adalah a. unary relationship d. binary relationshipb. N-ary relationship e. ternary relationshipc. M-ary relationship

1. Suatu network yang menggambarkan suatu sistem automatic/komputerisasi , manual dan gabungan dari keduanya dalamsusunan berbentuk komponen sistem yang saling berhubungansesuai dengan aturan mainnyaa. DFD d. entityb. proses e. jaringan c. entitas

Pertemuan 9

PRINSIP DAN KONSEP DESAINPRINSIP DAN KONSEP DESAIN


� Desain PL dan Rekayasa PL� Prinsip Desain� Konsep Desain� Konsep Desain� Desain Modular Afektif� Model Desain� Dokumentasi Desain

• Pressman, RS., 2008, Software Engineering: A Practitioner’s Approach,

Buku Referensi :

Engineering: A Practitioner’s Approach, New York: McGraw-Hill

• Sommerville, I, 2007, Software Engineering, Addsion Wesley

TUJUAN PRINSIP DAN KONSEP DESAIN

• Memahami konsep dan prinsip desain PL

• Mengerti desain secara modular dapat mengurangi

kompleksitas program dan mudah dimplementasikan

• Memahami model desain

• Membuat dan mengetahui isi dari dokumentasi

DESAIN PL DAN REKAYASA PL

• Hal yang harus diperhatikan :

• Desain Data

Transformasi model domain informasi ke dalam struktur data. Obyek dan

hubungan data ditetapkan dalam ERD, isi data detail digambarkan dalam kamus

data.

• Desain Arsitektur

Menentukan hubungan antara elemen struktur utama dari program.Menentukan hubungan antara elemen struktur utama dari program.

• Desain Interface

Bagaimana PL berkomunikasi dalam dirinya sendiri, dengan sistem dan

manusia. Interface mengimplikasikan aliran informasi, data dan diagram aliran

kontrol memberikan informasi yang dibutuhkan bagi desain interface.

• Desain Prosedural

Mentransformasikan elemen struktural dari arsitektur program ke dalam suatu

deskripsi prosedural dari komponen PL. Informasi yang diperoleh dari PSPEC,

CSPEC dan STD berfungsi sebagai dasar bagi desain prosedural.

DESAIN PL DAN REKAYASA PL (lanjutan)

PROSES DESAIN

Desain dan Kualitas

• Desain harus mengimplementasikan semua

kebutuhan eksplisit yang ada dalam model analisis,

dan dia harus mengakomodasi semua kebutuhan

implisit yang diinginkan oleh konsumen.

• Desain harus dapat berupa panduan yang dapat• Desain harus dapat berupa panduan yang dapat

dibaca dan dipahami oleh orang-orang yang akan

membuat kode, dan mereka yang menguji serta

nantinya mendukung PL tersebut.

• Desain harus menyediakan gambaran utuh dari PL,

menggambarkan domain data, fungsional, dan

perilaku dari perspektif implementasi.

Panduan Kualitas

• Sebuah desain harus menampilkan arsitektur yang

1. Dibuat menggunakan pola atau style arsitektural yang sudah

dikenal,

2. Terdiri dari komponen-komponen yang menunjukkan karakteristik

desain yang baik dan

3. Dapat diimplementasi dalam bentul yang evolusioner.3. Dapat diimplementasi dalam bentul yang evolusioner.

– Untuk sistem yang lebih kecil, desain kadang dapat

dikembangkan secara linear.

• Sebuah desain harus berbentuk modular; oleh karena itu PL harus

secara logis dipartisi menjadi beberapa elemen subsistem

• Sebuah desain harus berisi representasi yang berbeda dari data

,arsitektur, antarmuka, dan komponen.

Panduan Kualitas (lanjutan)

• Sebuah desain harus menuju struktur data yang tepat untuk class-

class yang akan diimplementasi dan digambar dari pola data yang

dikenal.

• Sebuah desain harus menuju komponen-komponen yang

menunjukkan karakteristik fungsional yang dindpeneden.

• Sebuah desain harus menuju antarmuka yang mengurangi • Sebuah desain harus menuju antarmuka yang mengurangi

kompleksitas koneksi antara kompoenen-komponen dan dengan

lingkungan eksternal.

• Sebuah desain harus diturunkan menggunakan method berulang

yang diatur oleh informasi yang disebut selama analisis kebutuhan

PL.

• Desain harus direpresentasikan menggunakan notasi yang secara

efektif mengkomunikasikan maknanya.

Evolusi Desain PL

• Karakteristik Umuj :

1. Mekanisme penerjemahan suatu model analisis ke

dalam representasi desain.

2. Notasi untuk merepresentasikan komponen-komponen

fungsional dan interfacenya.

3. Heuristik bagi penyaringan dan partisi.3. Heuristik bagi penyaringan dan partisi.

4. Pedoman bagi penilaian kualitas.

PRINSIP DESAIN

Menurut Davis :

• Proses desain tidak boleh berjalan dengan “kacamata

kuda”

• Proses desain harus bisa dirujuk dari model analisis.

• Proses desain tidak boleh mengulang penemuan-

penemuan dasar. penemuan dasar.

• Desain harus dapat meminimalkan jarak intelektual

antara PL dan permasalah yang ada di dunia nyata.

• Desain harus menampakkan keseragaman dan

integrasi.

PRINSIP DESAIN (lanjutan)

• Desain harus terstruktur untuk mengakomodasi

perubahan.

• Desain harus terstruktur untuk turun secara

bertahap, walaupun ketika data, event, atau kondisi

operasi yang menyimpang ditemui.

• Desain bukan coding dan coding bukan desain. • Desain bukan coding dan coding bukan desain.

• Desain harus dapat dipantau kualitasnya mulai dari

dia dibuat, bukan setelah jadi.

• Desain harus direview untuk meminimalkan

kesalahan semantik (konseptual).

KONSEP – KONSEP DESAIN

• Konsep desain PL fundamental memberikan kerangka kerja untuk mendapatkan program yang berfungsi dengan benar.

• Konsep Dasar :

• abstraksi—data, prosedur, kontrol

• arsitektur—Struktur keseluruhan PL

• Patterns/pola—”memuat esensi” dari solusi desain yang sudah terbuktiterbukti

• modularitas—Pembagian data dan fungsi

• menyembunyikan—interface terkendali

• Independensi fungsi—single-minded function dan low coupling

• refinement—elaborasi detail dari semua abstraksi

• Refactoring—sebuah teknik reorganisasi yang menyederhanakan desain

Abstraksi Data

Abstraksi Prosedur

Penyaringan

• Penyaringan Stepwise adalah strategi desain top down yang

diusulkan ole Wiklaus Wirth.

• Penyaringan sebenarnya adalah proses elaborasi . Dimulai

dengan suatu statemen fungsi pada suatu tingkat abstraksi

tinggi.

• Statemen fungsi adalah statemen yang menggambarkan • Statemen fungsi adalah statemen yang menggambarkan

fungsi atau informasi secara konseptual.

• Penyaringan membantu desainer untuk mengungkapkan

detail tingkat rendah ketika desain berjalan.

Modularitas

• Meyer : 5 kriteria mengevaluasi metode

desain

1. Dekomposabilitas Modular� dekomposisi

2. Komposabilitas Modular

3. Kemampuan Pemahaman Modular3. Kemampuan Pemahaman Modular

4. Kontinuitas Modular

5. Ptoreksi Modular

Arsitektur PL

• Shaw dan Garlan : sekumpulan properti sebagai bagian dari

desain arsitektural :

1. Properti Struktural

spek representasi desain arsitektur ini menentukan

komponen-komponen sebuah sistem (mis: modul, objek,

filter), dan pola komponen-komponen tersebut dipaket dan

berinteraksi satu dengan yang lain. Sebagai contoh: objekberinteraksi satu dengan yang lain. Sebagai contoh: objek

dipaket untuk enkapsulasi baik data dan proses yang

memanipulasi data dan berinteraksi dengan invokasi method

Arsitektur PL (lanjutan)

2. Properti Ekstra Fungsional

Deskripsi desain arsitektur harus menggambarkan

bagaimana arsitektur mencapai kebutuhan kinerja,

kapasitas, reliabilitas, keamanan, adaptabilitas, dan

karakteristik sistem yang lain.

3. Keluarga dari sistem yang berhubungan

Desain arsitektur harus dapat menggambar pola-pola yang

diulang, yang secara umum ditemukan dalam disain keluarga

atau sistem yang mirip. Esensinya, desain harus mempunyai

kemampuan untuk menggunakan kembali blok-blok

bangunan arsitektur.

Patern / Pola

Design Pattern Template

• Nama Pattern—menggambarkan esensi pattern dalam nama yang singkat tapi ekspresif Intent/Tujuan—menjelaskan pattern dan apa yang dilakukan

• Juga dikenal sebagai/Also-known-as—Daftar sinonim untuk pattern terkait

• Motivation/Motivasi—menyediakan contoh masalah

• Aplikabilitas—menjelaskan situasi desain spesifik dimana pattern • Aplikabilitas—menjelaskan situasi desain spesifik dimana pattern dapat diterapkan

• Struktur—menggambarkan class yang dibutuhkan untuk implementasi pattern

• Participants—menggambarkan tanggungjawab class-class yang diperlukan untuk mengimplementasikan pattern

• Collaborations—menggambarkan bagaimana participan berkolaborasi untuk memikul tanggung jwabanya.

• Konsekuensi—menggambarkan pengaruh desain terhadap pattern dan potensi masalah yang harus diperhatikan ketika pattern diimplementasi.

• Related patterns—relasi referensi silang design patterns

Hierarki Kontrol

• Disebut juga struktur program.

• Yang paling umum digunakan adalah diagram pohon

• Depth dan width mengindikasikan jumlah modul yang dikontrol dan rentang keseluruan kontrol

• Fan-out pengukuran jumlah modul yang dikontrol secara langsung oleh modul yang lain.

• Fan-in mengindikasikan berapa banyak modul yang secara langsung mengontrol sebuah modul yang diberikan.mengontrol sebuah modul yang diberikan.

• Hubnugan kontrol diantara kontrol :

– Superordinat (modul yang mengontrol modul lain).

– Subordinat (modul yang dikontrol modul lain

• Visibilitas (komponen program yang dapat dipakai sebagai data oleh komponen lainnya)

• Konektivitas (Komponen yang dipakai secara tidak langsung oleh sebuah modul yang ditetapkan)

Hierarki Kontrol (lanjutan)

Partisi Struktural

• Partisi Vertikal

• Didesain sehingga pengambilan keputusan dan pekerjaan

distratifikasi

• Modul pengambilan keputusan tetap ada di puncak arsitektur

decisiondecision--makersmakers

workersworkers

Partisi Struktural (lanjutan)

• Partisi Horizontal

• Tentukan cabang yang terpisah pada hierarki modul untuk

setiap fungsi utama

• Gunakan modul kontrol untuk koodinasi komunikasi antar

fungsi2x

function 1function 1 function 3function 3function 1function 1 function 3function 3

function 2function 2

Struktur Data

• Struktur Data menentukan :

• Organisasi dan kompleksitas

• Item Skalar

• Metode akses

• Vektor Sekuensial

DESAIN MODULAR AFEKTIF

• Mudah untuk dibangun, mudah untuk dirubah dan mudah untuk ditetapkan…

Modularitas

• Berapakah jumlah modul yang pas untuk desainPL tertentu?

Penyembunyian Informasi

Mengapa Informasi disembunyikan?

• Mengurangi “efek samping”

• Membatasi pengaruh global dari keputusan

desain lokal

• Menekankan komunikasi melalui interface yang

terkendaliterkendali

• Mengurangi penggunaan data global

• Merujuk pada enkapsulasi—sebuah atribut dari

desain kualitas tinggi

• Menghasilkan PL dengan kualitas tinggi

Langkah-langkah Refinement

Indepedensi Fungsi

• Kohesi

Suatu ekstensi natural dari konsep penyembunyian informasi

• Kohesif Koisidental

Modul yang melakukan serangkaian tugas yang saling

berhubungan secara lepas.

• Kohesif secara Logis• Kohesif secara Logis

Modul yang melakukan tugas-tugas yang berhubungan secara

logis.

• Kohesif Temporal

Modul berisi tugas-tugas yang berhubungan dengan kenyataan

bahwa semua harus dieksekusi dalam jangkauan waktu yang

sama.

Indepedensi Fungsi (lanjutan)

• Modul melakukan tugas :

1. Menghitung data suplemen yang didasarkan pada data yang

dihitung secara orisinil.

2. Menghasilkan laporan kesalahan pada workstation pemakai.

3. Melakukan kalkulasi follow up yang diminta oleh pemakai.

4. Memperbaharui basis data.

5. Memungkinkan pemilian menu untuk pemesanan berikutnya.

• Kohesif Prosedural

Elemen pemrosesan dari suatu modul dihubungkan dan harus

dieksekusi dalam suatu urutan yang spesifik.

• Kohesi Komunikasional

• Semua elemen pemrosesan berkonsentrasi pada satu area dari

suatu struktur data.

Perangkaian

Perangkaian :

Pengukuran interkoneksi diantara modul-modul pada sebuah

struktur program

Heuristik Desain

1. Evaluasi ”iterasi pertama” dari struktur program untuk

mengurangi perangkaian dan meningkatkan kohesi.

2. Usahakan meminimalkan struktur dengan fan-out yang

tinggi ; usahakan untuk melakukan fan-in pada saat

kedalaman bertambah.

3. Jaga lingkup efek dari suatu modul ada dalam lingkup kontrol

dari modul itu.

4. Evaluasi interface modul untuk mengurangi kompleksitas

dan redudansi dan meningkatkan konsistensi

Perangkaian (lanjutan)

5. Tetapkan modul-modul yang fungsinya dapat diprediksi,

tetapi hindari modul yang terlalu restriktif.

6. Usahakan modul–modul ”entri terkontrol” menghindari

”hubungan patologis”dengan

7. Kemaslah PL berdasarkan batasan desain dan persyaratan.

MODEL DESAIN

• Direpresentasikan sebagai sebuah piramid.

Konsep Desain OO

• Desain Class

- Entity classes

- Boundary classes

- Controller classes- Controller classes

• Inheritance—semua tanggung jawab superclass akan diwarisi

oleh semua subclassnya

• Messages—stimulasi beberapa perilaku yang dapat terjadi

pada objek penerima pesan

• Polymorphism—sebuah karakteristik yang mengurangi usaha

yang dibutuhkan untuk memperluas desain

DESAIN CLASS

• Analisis class disempurnakan dalam desain untuk menjadi class-class entitas

• Class-class boundary dikembangkan selama desain untuk membuat interface(mis. Layar interaktif atau laporan cetak) yang dilihat pengguna dan berinteraksi.

- Class-class boundary didesain dengan tanggungjawab untuk mengelola cara objek entitas ditampilkan kepada user. mengelola cara objek entitas ditampilkan kepada user.

• Class-class control didesain untuk mengelola :

- Pembuatan atau perubahan objek entitas;

- nstansiasi object boundary dengan mengambil informasi dari objek entitas;

- Komunikasi kompleks antara sekelompok objek;

- Validasi data yang dikomunikasikan antar objek atau antar pengguna dan aplikasi.

Inheritance

• Pilihan-pilihan desain :

- Class dapat didesain dan dibangun dari nol. Jika demikian, inheritance tidak digunakan.

- Hierarki class dapat dicari untuk mencari kemungkinan jika sebuah class yang lebih tinggi pada hierarki (superclass) memiliki atribut-atribut dan operasi-operasi yang paling banyak dibutuhkan. Class baru ini diturunkan dari superclass dan beberapa tambahan dapat diberikan jika dibutuhkan.banyak dibutuhkan. Class baru ini diturunkan dari superclass dan beberapa tambahan dapat diberikan jika dibutuhkan.

- Hierarki class dapat di restrukturisasi sehingga atribut-atribut dan operasi-operasi yang dibutuhkan dan diturunkan oleh class baru tersebut.

- Karakteristik dari class yang sudah ada dapat di override dan atribut-atribut dan operasi-operasi dengan versi berbeda dapat diimplementasikan untuk class baru tersebut.

Message

Polymorphism

• Pendekatan konvensional

case of graphtype:

if graphtype = linegraph then DrawLineGraph (data);

if graphtype = piechart then DrawPieChart (data);

if graphtype = histogram then DrawHisto (data);

if graphtype = kiviat then DrawKiviat (data);if graphtype = kiviat then DrawKiviat (data);

end case;

• Semua graphs menjadi subclass dari class umum yang disebut

graph. Menggunakan konsep over loading, setiap subclass

mendefinisikan operasi yang disebut draw. Sebuah object

dapat mengirim pesan draw pada salah satu instansiasi objek

dari salah satu subclassnya. Objek yang menerima message

akan menjalankan operasi draw nya sendriri untuk membuat

graph yang sesuai..

Model Desain

Elemen Model Desain

• Elemen-elemen Data

Data model --> struktur data

Data model --> arsitektur database

• Elemen-elemen arsitektur

Domain aplikasi

Class-class analisis, relasinya, kolaborasi dan perilaku diubah menjadi

realisasi desainrealisasi desain

Patterns dam “styles” (Chapter 10)

• Elemen-elemen interface

user interface (UI)

Interface external pada sistem lain, piranti-piranti, jaringan-jaringan

atau produsen maupun konsumen informasi lainnya

Interface internal antara komponen-komponen desain.

• Elemen-elemen komponen

• Elemen-elemen deploy

Elemen Interface

Elemen Komponen

Elemen Deployment

Design Pattern

• Desainer terbaik di segala bidang tetap mempunyai keterbatasan

untuk melihat pola yang mencirikan sebuah masalah dan

menghubungkannya dengan pola yang dapat dikombinasikan untuk

membuat solusi

• Sebuah deskripsi dari design pattern dapat juga dilihat sebagai

sekumpulan design forces.

Design forcesmenjelaskan kebutuhan non fungsional (misalkan Design forcesmenjelaskan kebutuhan non fungsional (misalkan

:

kemudahan perawatan, portabilitas) yang dihubungkan

dengan PL

dimana pattern akan diaplikasikan.

• Karakteristik pattern (class, tanggungjawab, dan kolaborasi)

mengindikasikan atribut-atrobit desain yang harus diatur untuk

memungkinkan pattern mengakomodasi permasalahan yang

bervariasi

Frameworks

• Sebuah framework bukan merupakan pattern

arsitektur, namun lebih merupakan kerangka dengan

sekumpulan “plug points” (yang juga disebut

hooksdan slots) yang memungkinkannya untuk

beradaptasi dengan domain permasalahan tertentu.

• Gamma et al mencatat bahwa:• Gamma et al mencatat bahwa:

Design patterns lebih abstrak dari frameworks.

Design patterns adalah elemen-elemen

arsitektural yang lebih kecil daripada frameworks

Design patterns lebih umum daripada

frameworks

DOKUMENTASI DESAIN

• Ruang lingkup

a. sasaran sistem

b. persyaratan utama PL

c. batasan dan pembatasan desain

• Desain Data

a. Obyek dan struktur data resultan

b. Struktur file dan databaseb. Struktur file dan database

1. struktur file eksternal

2. data global

a. struktur logis

b. deskripsi record logis

c. metode akses

3. file dan referensi lintas data

DOKUMENTASI DESAIN (lanjutan)

• Desain arsitektural

a. Kajian data dan aliran kontrol

b. Struktur program yang diperoleh

• Desain interface

a. Spesifikasi interfacde manusia – mesin

b. Aturan desain interface manusia – mesin

c. Desain interface eksternalc. Desain interface eksternal

1. Interface untuk data eksternal

2. Interface untuk sistem atau peralatan eksternal

• Desain prosedural

Untuk masing-masing model

a. Naratif pemrosesan

b. Deskripsi interface

c. Deskripsi bahasa (atau lainnya) desain

DOKUMENTASI DESAIN (lanjutan)

c. Deskripsi bahasa (atau lainnya) desain

d. Modul yang digunakan

e. Struktur data internal

f. Keterangan / larangan / pembatasan

• Persyaratan lintas referensi

• Ketentuan Pengujian

– Panduan pengujian– Panduan pengujian

– Strategi integrasi

– Pertimbangan khusus

• Catatan Khusus

• Lampiran

Pertemuan 10

METODE DESAIN (1)METODE DESAIN (1)


� Desain Data� Desain Arsitektur� Proses Desain Arsitektur� Proses Desain Arsitektur� Pasca Pemrosesan Desain� Optimasi Desain Arsitektur


Buku Referensi :



Tujuan Metode Desain

• Menjelaskan maksud dari arsitektur PL dan

kenapa sangat penting.

• Memhami model data, struktur data,

database, data warehouse, desain data pada database, data warehouse, desain data pada

level komponen

DESAIN DATA• Aktivitas pertama (dan beberapa sering mengatakan yang terpenting) dari 4

aktivitas desain yang dilakukan selama RPL.

• Prinsip-prinsip :

1. Prinsip analisis sistematik yang diaplikasikan pada fungsi dan perilaku seharusnya

diaplikasikan juga pada data.

2. Semua struktur data dan operasi yang dilakukan pada masing-masing struktur

data harus diidentifikasi. data harus diidentifikasi.

3. Kamus data harus dibangun dan digunakan untuk menentukan baik data

maupun desain program.

4. Keputusan desain data tingkat rendah harus ditunda sampai akhir proses desain.

5. Representasi stuktur data hanya boleh diketahui oleh modul-modul yang harus

menggunakan secara langsung data yang diisikan didalam struktur terseb ut.

6. Pustaka struktur data dan operasi yang berguna yang dapat diaplikasikan pada

struktur data tersebut harus dikembangan.

7. Desain PL dan bahasa pemrograman harus mendukung spesifikasi dan realisasi

dari tipe-tipe data absktrak.

DESAIN ARSITEKTUR

• Untuk mengembangkan struktur program modular dan

merepresentasikan hubungan kontrol antar modul.

• Membentuk struktur program dan struktur data dengan

menentukan interface yang memungkinkan data mengalir

melalui program.melalui program.

• Kontributor

Perintis desain PL yang didasarkan pada aliran data melalui

sebuah sistem.

• Area Aplikasi

luasnya aplikasi dimana aplikasi dapat diaplikasikan.

PROSES DESAIN ARSITEKTUR

Langkahnya :

1. Tipe aliran informasi dibangun

2. Batas aliran diindikasikan.

3. DFD dipetakan kedalam struktur program.3. DFD dipetakan kedalam struktur program.

4. Hierarki kontrol ditentukan dengan pemfaktoran.

5. Struktur resultan disaring/diperhalus dengan

menggunakan pengukuran desain dan heuristik.

PROSES DESAIN ARSITEKTUR (lanjutan)

• Aliran Transformasi

Keseluruhan aliran data terjadi dalam cara yang berurutan

dan mengikuti satu atau hanya beberapa jalur “garis lurus”,

bila segmen dari aliran data menunjukkan karakteristik

tersebut, maka disitu ada aliran transformasi.tersebut, maka disitu ada aliran transformasi.

• Aliran transaksi

Ditandai dengan pergerakan data sepanjang jalur masuk yang

mengkonversikan informasi dunia eksternal ke dalam suatu

transaksi.

Karakteristik Aliran

PEMETAAN TRANSFORMASI

• Serangkaian langkah desain yang mengijinkan sebuah DFD dengan

karakteristik aliran transformasi untuk dipetakan ke dalam tempalte yang

telah ditentukan untuk struktur program.

• Langkah-langkah :

1. Kaji model sistem fundamental.

2. Kaji dan saring diagram aliran data untuk PL.2. Kaji dan saring diagram aliran data untuk PL.

3. Tentukan apakah DFD memiliki karakteristik aliran transformasi atau

transaksi.

4. Isolasi pusat transformasi dengan mengkhususkan batas aliran masuk

dan keluar.

5. Lakukan “pemfaktoran tingkat pertama”.

6. Lakukan “pemfaktoran tingkat kedua”.

7. Saringlah struktur program iterasi pertama dengan menggunakan

heuristik desain bagi kualitas perangkat lunak yang telah ditingkatkan.

PEMETAAN TRANSFORMASI (LANJUTAN)

data flow model

ab

c

d e fg h

ij

"Transform" mappingx1

x2 x3 x4

b c

a

d e f g i

h j

PEMETAAN TRANSAKSI

Langkah-langkah desain :

1. Kaji model sistem fundamental.

2. Kaji dan saring diagram aliran data untuk PL.

3. Tentukan apakah DFD memiliki karakteristik aliran transformasi atau transaksi.

4. Identifikasi pusat transaksi dan karakteristik aliran sepanjang 4. Identifikasi pusat transaksi dan karakteristik aliran sepanjang masing-masing jalur aksi.

5. Petakan DFD pada sebuah struktur program yang sesuai dengan pemrosesan transaksi.

6. Faktorkan dan saringkan struktur transaksi dan struktur masing-masing jalur aksi.

7. Saring struktur program iterasi pertama dengan menggunakan heuristik desian untuk kualitas PL yng dikembangkan.

PEMETAAN TRANSAKSI (lanjutan)

ProgramProgramArchitectureArchitecture

PASCA PEMROSESAN DESAIN

Tugas yang harus dilakukan :

• Mengembangkan narasi pemrosesn untuk masing-

masing modul.

• Menyediakan deskripsi interface untuk masing-

masing modul.masing modul.

• Menentukan struktur data lokal dan global.

• Mencatat semua batasan desain.

• Mengkaji desain.

• Mempertimbangkan “optimasi” (bila diperlukan dan

dibenarkan).

OPTIMASI DESAIN ARSITEKTURPendekatan :

1. Kembangkan dan saring struktur program tanpa memperatikan

optimasi kinerja-kritis.

2. Gunakan Peranti CASE yang mensimulasi kinerja run-time untuk

mengisolasi area inefisiensi.

3. Selama iterasi desain selanjutnya, pilihlan judul yang dicurigai

“time-hot” dan dengan hati-hati kembangkanlah prosedur“time-hot” dan dengan hati-hati kembangkanlah prosedur

(algoritma) untuk efisiensi waktu.

4. Kodekan sebuah bahasa pemrograman yang sesuai.

5. Instrumentasikan PL untuk mengisolasi modul yang menjelaskan

utilisasi proses yang berat.

6. Bila perlu, desain ulang atau kodekan kembali bahasa yang

tergantung pada mesin untuk meningkatkan efisiensi.

Pertemuan 11

METODE DESAIN (2)METODE DESAIN (2)


� Desain Interface� Desain Interface Manusia – Mesin� Desain Prosedural� Desain Prosedural� Coding


Buku Referensi :



Tujuan Metode Desain

• Menjelaskan maksud dari arsitektur PL dan

kenapa sangat penting.

• Memhami model data, struktur data,

database, data warehouse, desain data pada database, data warehouse, desain data pada

level komponen

DESAIN INTERFACE• Memfokuskan diri pada 3 area perhatian :

1. Desain interface antara modul-modul PL.

2. Desain interface antara PL dan prosedur dan konsumen informasi, bukan

manusia lainnya (yakni entitas eksternal lainnya).

3. Desain interface antara seorang manusia (user) dan komputer.

Desain interface pemakai internal Desain interface pemakai internal

(desain interface inter-modular) dikendalikan oleh data yang harus

mengalir diantara modul-modul dan karakteristik bahasa pemrograman

dimana PL akan diimplementasikan.

Desain interface pemakai eksternal

Dimulai dengan evaluasi terhadap masing-masing entitas eksternal yang

direpresentasikan pada DFD model analisis.

Desain Interface Pemakai

Berkaitan dengan studi terhadap manusia juga terhadap isu-isu teknologi

DESAIN INTERFACE MANUSIA MESIN

Dimulai dengan membuat model-model fungsi sistem yang

berbeda-beda. Kemudian digambarkan tugas yang

berorientasi pada manusia dan komputer yang dibutuhkan

untuk mencapai fungsi sistem.

Model-Model Desain InterfaceModel-Model Desain Interface

1. Model Desain

Menggabungkan data, arsitektur, interface, dan representasi

prosedural dari PL

1. Model Pemakai

2. Persepsi Sistem

3. Cara Sistem

DESAIN INTERFACE MANUSIA MESIN (lanjutan)

2. Model Pemakai

Menggambarkan para pemakai akhir dari sistem, meliputi

profil, usia, jenis kelamin, kemampuan fisik, pendidikan, latar

belakang etnis dan kultural, motivasi, tujuan dan

kepribadian.

3. Persepsi Sistem

Citra sistem yang ada dikepala seorang pemakai akhir.

4. Cara Sistem

merangkai manifestasi bagian luar dari sistem berbasis

komputer, dengan semua informasi yang mendukung, yang

menggambarkan siteksis dan semantik sistem.


Pemodelan dan Analisis Tugas

Proses desain interface :

1. Tentukan tujuan untuk tugas.

2. Petakan tujuan untuk serangkaian aksi khusus.

3. Tentukan urutan aksi saat tindakan akan dieksekusi pada3. Tentukan urutan aksi saat tindakan akan dieksekusi pada

tingkat interface.

4. Indikasikan keadaan sistem.

5. Tentukan mekanisme kontrol.

6. Perlihatkan bagaimana mekanisme kontrol mempengaruhi

keadaan sistem.

7. Indikasikan bagaimana pemakai menginterpretasi keadaan

sistem dari informasi yang diberikan melalui interface.


Masalah desain :

1. Apakah help dapat diperoleh untuk semua fungsi sistem .

2. Bagaimana pemakai memperoleh help

3. Bagaimanan help akan direpresentasikan

4. Bagaimana pemakai kembali ke interaksi normal.4. Bagaimana pemakai kembali ke interaksi normal.

5. Bagaimana informasi help distruktur.


Peranti Implementasi

User Interface Development :

- Mengatur perangkat input (mouse / keyboard)

- Menvalidasi input pemakai.

- Menangani kesalahan dan menampilkan pesan kesalahan.- Menangani kesalahan dan menampilkan pesan kesalahan.

- Memberikan umpan balik.

- Menyediakan help dan promt.

- Penanganan jendela dan field, scrolling paa jendela.

- Membangun koneksi antara PL aplikasi dan interface.

- Mengisolasi aplikasi dari fungsimanajemen interface.

- Memungkinkan pemakai mengkostumasi interface.


Evaluasi Desain

- Panjang dan kompleksitas spesifikasi tertulis dari sistem dan interfacenya, mengindikasikan jumlah waktu belajar yang dibutuhkan para pemakai sistem.

- Jumlah perintah atau aksi yang ditentukan dan jumlah rata-rata argumen per perintah atau operasi individual per aksi, megindikasikan waktu interaksi dan efisiensi keseluruhan megindikasikan waktu interaksi dan efisiensi keseluruhan dari sistem tersebut.

- Jumlah aksi, perintah, dan keadaan sistem yang diindikasikan oleh model desain, menunjukkan beban memori pada pemakai sistem.

- Gaya interface, fasilitas help dan protokol penanganan kesalaan memberikan suatu indikasi umum mengenai komplesitas interface dan tingkat dimana interface akan diterima oleh pemakai.


- Siklus evaluasi desain interface

Desain

Permulaaan

Membuat

Prototipe

Interface #1Membuat

Prototipe

Interface #n

Pemakai

mengevaluasi

interface

Interface #n

Modifikasi

desain

dilakukan

Evaluasi

dipelajari oleh

desainerDesain Interface dilengkapi

PEDOMAN DESAIN INTERFACE1. Interaksi Umum

- Konsisten

- berikan umpan balik

- Verifikasi terhadap aksi destruktif yang signifikan.

- kemudahan pembatalan sebagian besar aksi.

- kurangi jumlah informasi yang harus diingat diantara aksi-

aksi.aksi.

- Adanya efisiensi dalam dialog, gerakan dan pemikiran.

- Memaafkan kesalahan

- Kategorikn aktivitas menurut fungsidan atur geografi layar.

- Sediakan fasilitas elp yang sensitif.

- Gunakan verbal aksi yang sederana untuk menerima

perintah.

PEDOMAN DESAIN INTERFACE (LANJUTAN)

2. Tampilan Informasi

� Hanya menampilkan informasi yang relevan dengan konteks yang ada.

� Jangan membanjiri pemakai dengan data.

� Gunakan label yang konsisten, penyingkatan standar dan warna yang

dapat diprediksi.

� Ijinkan pemakai untuk memelihara konteks visual.� Ijinkan pemakai untuk memelihara konteks visual.

� Hasilkan pesan kesalahan yang berarti.

� Gunakan huruf besar dan kecil, identasi dan pengelompokkan teks untuk

membantu pemahamannggolongkan tipe informasi

� Gunakan jendela untuk mengolongkan tipe informasi yang berbeda.

� Gunakan tampilan “analog” untuk merepresentasikan informasi yang

lebih mudah diasimilasikan dengan bentuk representasi ini.

� Pertimbangkan ketersediaan gfeografi layar tampilandan gunakan secara

efisien.

PEDOMAN DESAIN INTERFACE (LANJUTAN)

3. Input Data

� Minimalkan jumlah aksi input yang dibutuhkan dari pemakai.

� Jaga konsistensi diantara tampilan informasi dan input data.

� Ijinkan pemakai mengkustomasi input.

� Interaksi harus fleksibel, tetapi juga diatur ke mode input yang disukai � Interaksi harus fleksibel, tetapi juga diatur ke mode input yang disukai

pemakai.

� Nonaktifkan perintah yang tidak sesuai di dalam konteks aksi yang

sedang berlangsung.

� Biarkan pemakai mengontrol aliran interkatif.

� Sediakan help untuk membantu semua aksi input.

� Hilangkan input “mickey mouse”.

DESAIN PROSEDURAL

• Terjadi setelah data, desain arsitektur dan interface

dibangun.

Pemrograman Terstruktur

Urutan

(langkah pemrosesan yang penting dalam spesifikasi (langkah pemrosesan yang penting dalam spesifikasi

sembarang algoritma).

Kondisi

(fasilitas bagi pemrosesan yang dipilih berdasarkan beberapa

kejadian logis).

Pengulangan

(menyediakan looping)

DESAIN PROSEDURAL (lanjutan)

Notasi Desain Grafis

Peranti grafis memberikan bentuk gambar yang bagus yang

telah menggambarkan detail prosedural.

Bagan Alir merupakan representasi grafis yang paling luas

dipakai.

Notasi Desain Berbentuk Tabel

Tabel keputusan memberikan sebuah notasi yang

menerjemahkan aksi-aksi dan kondisi ke dalam bentuk tabel.

DESAIN PROSEDURAL (lanjutan)

Langkah untuk mengembangkan tabel keputusan :

1. Daftarkan semua aksi yang dapat diasosiasikan dengan

sebuah prosedur tertentu (atau modul).

2. Daftarkan semua kondisi (atau keputusan yang dibuat) 2. Daftarkan semua kondisi (atau keputusan yang dibuat)

selama eksekusi prosedur.

3. Hubungkan serangkaian kondisi tertentu dengan aksi

tertentu, dengan mengeliminasi kombinasi dari kondisi yang

mungkin.

4. Tentukan aturan-aturan dengan menunjukkan aksi, apa yang

terjadi bagi serangkaian kondisi.

DESAIN PROSEDURAL (lanjutan)Baasa Desain Program (PDL) atau pseudocode :

“bahasa pasar“ yang menggunakan kosakata dari satu bahasa

dan keseluruhan sintaks dari yang lain.

Karakteristik bahasa desain :

1. Sintalks kata kunci (keyword) tersedia untuk semua gagasan1. Sintalks kata kunci (keyword) tersedia untuk semua gagasan

terstruktur, deklarasi data dan karakteristik modularitas.

2. Sintaks bebas dari bahasa natural yang menggambarkan ciri-

ciri pemrosesan.

3. Fasilitas deklarasi data yang harus meliputi struktur data

kompleks (linked list) dan sederhana (skalar, array).

4. Definisi subprogram dan teknik pemanggilan yang

mendukung berbagai mode deskripsi interface.

CODING

Pertemuan 12

IMPLEMENTASI

POKOK BAHASAN� Makna & Tujuan Implementasi

� Perencanaan Implementasi

� Hal Penting Dalam Implementasi

� Persiapan Dokumentasi

� Pemasangan Atau Konversi Sistem Baru Ke Sistem Lama

� Evaluasi Sistem Baru

� Lingkungan Pemrograman

� Programming Style

� Prinsip Portability & Reusable (Kemudahan & Penggunaan

� Ulang Komponen)

� CASE Tools

Makna & Tujuan Implementasi (1)

� Tahap implementasi merupakan tahap besar di akhirproduksi PL

� Tahap ini merupakan proses pembuatan kode programdalam bahasa pemrograman tertentu sesuai dengandalam bahasa pemrograman tertentu sesuai denganplatform dan kesepakatan dengan customer.

� Merupakan tahap transformasi dari hasil desain kedalam program yang dpt dijalankan pada komputeryang akan digunakan di dalam sistem.

� Baik buruknya implementasi sangat tergantung padabaik buruknya hasil final dari tahap desain

� Melibatkan pengintegrasian semua komponenrancangan sistem�termasuk PL, konversi ke sistemoperasi.

� Proses implementasi melibatkan:

Makna & Tujuan Implementasi (2)

� Proses implementasi melibatkan:

� Perencanaan

� Pengeksekusian

Rencana Implementasi (1)

� Rencana ini merupakan formulasi rinci danrepresentasi grafik mengenai cara pencapaianimplementasian sistem yang akan dilaksanakan(tergantung pada kompleksitas proyek)

� Tim implementasi yg terlibat:� Tim implementasi yg terlibat:

� Manajer dan beberapa staff

� Profesional sistem yang merancang sistem

� Perwakilan Vendor

� Pemakai Primer

� Pengcode/programmer

� Teknisi

Contoh Rencana Implementasi

Hal Penting Dalam Implementasi

1. Persiapan Tempat

� Diperlukan dokumentasi, yang perlu dipersiapkan :

� Ruang (sesuai dengan platform teknologi yangakan digunakan Micro, mini atau mainframe)

� Listrik, telepon, koneksi lainnya, ventilasi, AC,keset anti debu, karpet, rak, penyangga barang,meja, penyimpan disk/pita, lemari kabinet, tempatpersonil, lokasi printer, dudukan printer, danfurniture lain yg dirancang secara ergonomis

� Pengujian burn in (simulasi operasi pd vendor)

2. Pelatihan Personil� Tdk ada sistem yang bekerja secara memuaskan

jika para pemakai dan orang lain yang berinteraksidengan sistem tersebut tidak dilatih secara benar

� Pelatihan personil tidak hanya meningkatkan

Hal Penting Dalam Implementasi (2)

� Pelatihan personil tidak hanya meningkatkankeahlian/ketrampilan pemakai, namun jugamemudahkan penerimaan mereka terhadap sistembaru

� Pelatihan meningkatkan kepercayaan diri,meminimalkan sesi kesalahan, kerusakan padatahap awal.

� Sasaran pelatihan:

1. Personil teknis yang akan mengoperasikan danmemelihara sistem tersebut.

2. Berbagai pekerja dan supervisor yang akan berinteraksilangsung dengan sistem untuk mengerjakan tugas danmembuat keputusan


membuat keputusan

3. Manajer umum

4. Pihak luar yang berinteraksi dengan sistem

3. Cakupan Pelatihan:� Tutorial, mengajarkan cara menjalankan sampai pelatihan

untuk mengajarkan pokok2 sistem baru

4. Program Pelatihan:� Pelatihan in house

� Pelatihan yang disediakan oleh vendor

� Jasa pelatihan luar

5. Teknik dan Alat Bantu Pelatihan:


5. Teknik dan Alat Bantu Pelatihan:� Teleconferesi

� PL pelatihan interaktif

� Pelatihan dengan instruktur

� Pelatihan magang

� Manual prosedur

� Buku teks

6. Software Untuk Pelatihan Interaktif:� CBT (Computer-Based Training)� ABT (Audio-Based Training)� VBT (Video-Based Training)� VOD (Video-Optical Disc)


� VOD (Video-Optical Disc)

7. Persiapan/Pembuatan Dokumen� Dokumentasi adalah materi tertulis/video/audio yang

menjabarkan cara beroperasinya sebuah sistem,termasuk pokok bahasan yang harus dikuasi olehpemakai.

� Tujuan dokumentasi:1. Pelatihan2. Penginstruksian3. Pengkomunikasian4. Penetapan standar kinerja5. Pemeliharaan sistem


5. Pemeliharaan sistem6. Referensi historis

� Empat area utama dokumentasi:1. Dokumen pemakai2. Dokumen Sistem3. Dokumen Perangkat lunak4. Dokumen operasi

Penjelasan

Tanpa dokumentasi yang jelas dan akurat

Pengembangan sistem


Pengembangan sistem

8. Konversi File & Sistem

� Merupakan proses pengubahan dari sistem lama kesistem baru

� Kompleksitas dalam pengkonversian tergantungpada beberapa faktor, yaitu :

� Jenis Perangkat Lunak


� Jenis Perangkat Lunak

� Database

� HardWare

� Kendali

� Jaringan

� Prosedur

� Metode konversi:1. Konversi Langsung

Sistem yang lama langsung digantikan dengan sistemyang baru

2. Konversi ParalelSistem lama masih dijalankan sambil menjalankansistem baru, jika sistem baru sudah dianggap stabil


sistem baru, jika sistem baru sudah dianggap stabilmaka sistem lama akan dihentikan

3. Konversi Phase-inSistem lama digantikan secara berangsur angsur sedikitdemi sedikit akhirnya sistem lama akan tergantikandengan sistem baru

4. Konversi PilotDilakukan secara segmentasi bagian per bagian

Konversi ini baik dilakukan jika :� Sistem baru tidak menggantikan sistem lama� Sistem lama sepenuhnya tidak bernilai� Sistem baru bersifat kecil/sederhana� Rancangan sistem baru sangat berbeda dari sistem

lama

� Memberikan derajat proteksi yang tinggi dari kegagalansistem baru

� Biaya yang dibutuhkan cukup besar karena keduanyaharus jalan bersama-sama

� Sistem baru di implementasikan sedikit demi sedikituntuk menggantikan sistem lama

� Sistem harus disegmentasi� Perlu biaya tambahan utk membangun interface

temporer dg sistem lama� Proses implementasi membutuhkan waktu yang

panjang

� Perlunya segmentasi organisasi� Resiko lebih rendah dibandingkan metode konversi

langsung� Biaya lebih rendah dibanding metode paralel� Cocok digunakan apabila adanya perubahan prosedur,

HardWare, dan SoftWare

Konversi File Data

� Keberhasilan konversi sistem sangat tergantung padaseberapa jauh profesional sistem menyiapkan konversifile data yang diperlukan di dalam sistem baru

� Konversi/Modifikasi Meliputi:

� Format file� Format file

� Isi file

� Media penyimpanan

� Metode Dasar Konversi:

1. Konversi File Total

Dpt digunakan pada ke-4 metode konversi sistem

Konversi File Data (2)2. Konversi File Gradual

� Lebih banyak digunakan utk metode paralel danphase-in

� Selama konversi file perlu diperhatikan prosedurkendali untuk memastikan integrasi data

� Prosedur kendali utk masing2 file berbeda

� Suatu transaksi diterima dan dimasukkan ke dalamsistem

� Program mencari file master baru untuk record yangakan diupdate oleh transaksi tsb.jika record tsb adamaka pengupdatean record selesai

Konversi File Data (3)2. Konversi File Gradual (Lanjutan)

� Jika record tidak ditemukan dalam file master baru, filemaster lama diakses untuk record yang tepat, danditambahkan pada file master baru dan diupdate

� Jika transaksi untuk record baru, record baru disiapkandan ditambahkan ke file master baru.dan ditambahkan ke file master baru.

� Klasifikasi file:

� File Master

� File Transaksi

� File Index

� File Tabel

� File Backup

Tahapan Implementasi� Struktur dekomposisi, struktur data, dan identitas dipilih

dan di kerjakan sampai prosedur desain mudah untukditata ulang dalam sebuah implementasi

� Level abstraksi pada desain, misal class, modul,algoritma, struktur data, dan tipe data harus diwujudkandalam implementasidalam implementasi

� Antarmuka antara komponen sistem perangkat lunakharus diwujudkan secara jelas pada tahap implementasi

� Kode program tersebut harus dapat di cekkonsistensinya pada setiap objek dan operasinyasecara langsung menggunakan kompilator.

Kriteria Lingkungan Pemrograman1. Modularity (Modularitas)

Program dapat dibuat dalam bentuk modul2 yang lebihkecil dan mudah dalam integrasinya

2. Dokumentasi Nilai Pada Bahasa PemrogramanDokumentasi mengenai penjelasan coding/komponenyang digunakanyang digunakan

3. Struktur Data Dalam Bahasa PemrogramanKetersediaan struktur data yang kompleks akanmembantu mempermudah proses

4. Struktur Aliran PengendaliSuatu kasus khusus melibatkan suatu pengujian kondisidan akan memberikan alternatif untuk dilaksanakansesuai kondisi yang ada

Kriteria Lingkungan Pemrograman (2)

5. Efisiensi� Penulisan kode lebih singkat

� Pemakaian memori penyimpanan lebih kecil

� Hasil program dapat dijalankan dengan cepat

6. IntegritasKemudahan dalam pembacaan dan mekanisme dalamKemudahan dalam pembacaan dan mekanisme dalampengecekan tipe dan antarmodul

7. Portability (Multiplatform)Bahasa pemrograman atau hasil programnya dapatdijalankan di beberapa platform yang berbeda

8. Dukungan DialogFasilitas interaktif dari program dengan lingkungan luar


9. Quality

Kualitas kompilator sangat tergantung pada fitur-fituryang disediakan dan mampu mendukung kinerjapembuataan koding yang bekualitas.

10. Ketersediaan Pustaka (Library)10. Ketersediaan Pustaka (Library)

Menyediakan pustaka/library yang bervariasi untukaplikasi yang kompleks

11. Ketersediaan Tool Pembangunan

Semua peralatan terintegrasi dalam satu interface

12. Kebijakan Instansi (Tim)

Pemilihan bahasa pemrograman ditentukan olehinstitusi (tim) atau oleh penggunanya

13. Kebutuhan Eksternal

Adanya tambahan alat baru atau PL baru yang harus


Adanya tambahan alat baru atau PL baru yang harusterhubung dengannya

Programming Style

� Menulis sebuah program adalah seni dan merupakanproses yang kreatif

� Gaya pemrograman pada programmer mempengaruhitingkat kemudahan pembacaan program yang dibuatnya

� Buku Code Complete� Buku Code CompleteMengulas tuntas suatu gaya pemrograman bahkan didalamnya diberkan contoh variasi yang cukup banyak.

� Gaya pemrograman yang baik sangat didukung dari tahapdesain dan perencanaan implementasi yang baik

PERTEMUAN 13

STRATEGI PENGUJIAN STRATEGI PENGUJIAN PERANGKAT LUNAK

Strategi uji coba perangkat lunak dilakukan

untuk memudahkan para perancang untuk

menentukan keberhasilan system yang telah

dikerjakandikerjakan

Proses Testing

UnitTesting

ModuleTesting

Sub-systemTesting

SystemTesting

AcceptanceTesting

3

Component Testing Integration TestingUserTesting

Proses Testing� Unit testing

Pengujian masing-masing unit komponen program untuk meyakinkan bahwa sudah beroperasi secarabenar

� Module Testing

4

� Module TestingPengujian terhadap koleksi unit-unit komponen yang saling berhubungan.

� Sub-system TestingPengujian terhadap koleksi module-module yang membentuk suatu sub-system (aplikasi)

Proses Testing

� System TestingPengujian terhadap integrasi sub-system, yaituketerhubungan antar sub-system

� Acceptance Testing

5

� Acceptance Testing� Pengujian terakhirs sebelum sistem dipakai oleh

user. � Melibatkan pengujian dengan data dari pengguna

sistem.� Biasa dikenal sebagai “alpha test” (“beta test”

untuk software komersial, dimana pengujiandilakukan oleh potensial customer)

Rencana Pengujian

� Proses testingDeskripsi fase-fase utama dalam pengujian

� Pelacakan KebutuhanSemua kebutuhan user diuji secara individu

� Item yg diuji� Item yg diujiMenspesifikasi komponen sistem yang diuji

� Jadual Testing� Prosedur Pencatatan Hasil dan Prosedur� Kebutuhan akan Hardware dan Software� Kendala-kendala

Mis: kekuranga staff, alat, waktu dll.

Failure and Faults� Failure: output yang tidak benar/tidak sesuai ketika

sistem dijalankan� Fault: kesalahan dalam source code yang mungkin

menimbulkan failure ketika code yang fault tersebutdijalankan

Prioritas Testing� Hanya test yang lengkap yang dapat meyakinkan

sistem terbebas dari kesalahan, tetapi hal ini sangatsulit dilakukan.

� Prioritas dilakukan terhadap pengujian kemampuansistem, bukan masing-masing komponennya.

� Pengujian untuk situasi yang tipikal lebih penting� Pengujian untuk situasi yang tipikal lebih pentingdibandingkan pengujian terhadap nilai batas.

Test Data Dan Kasus Test

� Test DataInput yang direncanakan digunakan oleh sistem.

� Test CasesInput yang digunakan untuk menguji sistem danmemprediksi output dari input jika sistem beroperasimemprediksi output dari input jika sistem beroperasisesuai dengan spesifikasi.

Pendekatan Strategis Pengujian Perangkat Lunak

� Pengujian Unit� Pengujian Integrasi� Pengujian Validasi� Pengujian Validasi� Pengujian Sistem

Pengujian Unit

� Berfokus pada inti terkecil dari desain perangkatlunak yaitu modul

� Uji coba unit selalu berorientasi pada white boxtesting

� Dapat dikerjakan paralel atau beruntun dengan modul� Dapat dikerjakan paralel atau beruntun dengan modullainnya.

Pengujian Unit (2)

� Apakah jumlah parameter input sama dengan jumlahargumen?

� Apakah antara atribut dan parameter argumen sudahcocok?

� Apakah antara sistem satuan parameter dan argumensudah cocok?

Pengujian Unit (3)

sudah cocok?� Apakah jumlah argumen yang ditransmisikan ke modul

yang dipanggil sama dengan atribut parameter?� Apakah atribut dari argumen yang ditransmisikan ke

modul yang dipanggil sama dengan atribut parameter?� Apakah sistem unit dari argumen yang ditransmisikan

ke modul yang dipanggil sama dengan sistem satuanparameter?

� Apakah jumlah atribut dan urutan argumen ke fungsi-fungsi built-in sudah benar?

� Adakah referensi ke parameter yang tidak sesuai denganpoin entri yang ada?

� Apakah argumen input only diubah?

Pengujian Unit (4)

� Apakah definisi variabel global konsisten dengan modul ?� Apakah batasan yang dilalui merupakan argumen?

� Test case harus didesain untuk mengungkap kesalahandalam kategori1. Pengetikan yang tidak teratur dan tidak konsisten

inisialisasi yang salah atau nilai-nilai default2. Nama variabel yang tidak benar

Pengujian Unit (5)

3. Tipe data yang tidak konsisten4. Underflow, overflow dan pengecualian

pengalamatan

Seberapa Baik Sistem Yang Sudah di Bangun� Dua Aspek yang dipertimbangkan:

� Apakah implementasi sudah sesuai denganspesifikasi ?

� Apakah spesifikasi sesuai dengan kebutuhan user ?� Validasi

� Apakah sistem yang dikembangkan sudah benar?� Apakah sistem yang dikembangkan sudah benar?� Pengujian dimana sistem ketika diimplementasikan

sesuai dengan yang diharapkan� Verifikasi

� Apakah sistem dikembangkan dengan cara yangbenar ?

� Pengujian apakah sistem sudah sesuai denganspesifikasi

Integration Testing� Pengujian keseluruhan system atau sub-system yang

terdiri dari komponen yang terintegrasi. � Test integrasi menggunakan black-box dengan test

case ditentukan dari spesifikasi. � Kesulitannya adalah menemukan/melokasikan� Penggunaan Incremental integration testing dapat � Penggunaan Incremental integration testing dapat

mengurangi masalah tersebut.

T2

T1A

BT2

T1A

T1A

T3

T4

T5

C

D

T3

T4

B

C

T2

T3B

Test sequence1

Test sequence2

Test sequence3

Pendekatan Integration Testing

� Top-down TestingBerawal dari level-atas system dan terintegrasi dengan mengganti masing-masing komponen secara top-down dengan suatu stub (program pendek yg mengenerate input ke sub-system yang diuji).

� Bottom-up TestingIntegrasi components di level hingga sistem lengkap sudah teruji.

Pada prakteknya, kebanyakan test integrasi menggunakan kombinasi kedua strategi pengujian tsb.

Top Down Testing

Level 2Level 2Level 2Level 2

Level 1 Level 1Testing

sequence . . .

Level 2Level 2Level 2Level 2

Level 2stubs

Level 3stubs

Bottom Up Testing

Level NLevel NLevel NLevel NLevel NTesting

sequence

Testdrivers

Level N–1 Level N–1Level N–1

Testdrivers

Pendekatan Testing

� Architectural ValidationTop-down integration testing lebih baik digunakan dalam menemukan error dalam sistem arsitektur.

� System DemonstrationTop-down integration testing hanya membatasi pengujian pada awal tahap pengembangan system.

� Test ImplementationSeringkali lebih mudah dengan menggunakan bottom-up integration testing

Interface Testing� Dilakukan kalau module-module dan sub-system

terintegrasi dan membentuk sistem yang lebih besar� Tujuannya untuk medeteksi fault terhadap kesalahan

interface atau asumsi yang tidak valid tentang interface tersebut.

� Sangat penting untuk pengujian terhadap � Sangat penting untuk pengujian terhadap pengembangan sistem dengan menggunakan pendekatan object-oriented yang didefinisikan oleh object-objectnya

Pengujian Validasi

� Kajian Konfigurasi (audit)� Elemen dari proses validasi� Memastikan apakah semua elemen konfigurasi

perangkat lunak telah dikembangkan dengan tepat

� Pengujian Alpha dan Beta� Pengujian Alpha

� Usability labs� Usability factors checklist

� Pengujian Beta

Pengujian Sistem

� Pengujian Perbaikan� Pengujian Keamanan� Pengujian Stress� Pengujian Kinerja

Pengujian Aplikasi Server

� Volume Testing� Stress Testing� Performance Testing� Data Recovery Testing� Data Backup and Restore Testing� Data Backup and Restore Testing� Data Security Testing

Volume Testing� Menemukan kelemahan sistem selama melakukan

pemrosesan data dalam jumlah yang besar dalam periode waktu yang singkat.

� Tujuan: meyakinkan bahwa sistem tetap melakukan pemrosesan data antar batasan fisik dan batasan logik.

� Contoh:� Contoh:Mengujikan proses antar server dan antar partisi hardisk pada satu server.

Stress Testing

� Tujuan: mengetahui kemampuan sistem dalam melakukan transaksi selama periode waktu puncak proses.

� Contoh periode puncak: ketika penolakan proses login on-line setelah sistem down atau pada kasus batch, pengiriman batch proses dalam jumlah yang besar pengiriman batch proses dalam jumlah yang besar dilakukan setelah sistem down.

� Contoh: Melakukan login ke server ketika sejumlah besar workstation melakukan proses menjalankan perintah sql database.

Performance Testing� Dilakukan secara paralel dengan Volume dan Stress

testing untuk mengetahui unjuk kerja sistem (waktu respon, throughput rate) pada beberapa kondisi proses dan konfigurasi.

� Dilakukan pada semua konfigurasi sistem perangkat keras dan lunak. Misal : pada aplikasi Client-Server diujikan pada kondisi korporate ataupun lingkungan diujikan pada kondisi korporate ataupun lingkungan sendiri (LAN vs. WAN, Laptop vs. Desktop)

� Menguji sistem dengan hubungannya ke sistem yang lain pada server yang sama.

� Load Balancing Monitor� Network Monitor

Data Recovery Testing

� Investigasi dampak kehilangan data melalui proses recovery ketika terjadi kegagalan proses.

� Penting dilakukan karena data yg disimpan di server dapat dikonfigurasi dengan berbagai cara.

� Kehilangan Data terjadi akibat kegagalan sistem, hardisk rusak, peghapusan yang tidak sengaja, hardisk rusak, peghapusan yang tidak sengaja, kecelakaan, virus dan pencuri.

Data Backup dan Restore Testing

� Dilakukan untuk melihat prosedur back-up dan recovery.

� Diakukan dengan mensimulasikan beberapa kesalahan untuk menguj i proses backup dan recovery.

� Pengujian dilakukan terhadap strategi backup: frekuensi � Pengujian dilakukan terhadap strategi backup: frekuensi , medium, waktu, mekanisme backup (manual/ otomatis), personal, ? Berapa lama backup akan disimpan.

� Switching antara live dan backup server ketika terjadi kerusakan (load log transaction pada back-up kemudian melakukan recovery).

Data Security Testing

� Privilege access terhadap database diujikan padabeberapa user yang tidak memiliki privilege access kedatabase.

� Shutdown database engine melalui operating system(dengan beberapa perintah OS) yang dapat mematikanaplikasi database.aplikasi database.

Debugging

PERTEMUAN 14

TEKNIK PENGUJIAN TEKNIK PENGUJIAN

PERANGKAT LUNAKPERANGKAT LUNAK

TESTING� Pengujian perangkat lunak adalah proses menjalankan

dan mengevaluasi sebuah perangkat lunak secara manualmaupun otomatis untuk menguji apakah perangkat lunaksudah memenuhi persyaratan atau belum, atau untukmenentukan perbedaan antara hasil yang diharapkandengan hasil sebenarnya.

� Pengujian merupakan suatu tahapan pengerjaan yang� Pengujian merupakan suatu tahapan pengerjaan yangbertujuan mencari kesalahan program. Kesalahan yangterjadi selama proses pengembangan perangkat lunakakan mengakibatkan bertambahnya waktu untukmenyelesaikan pekerjaan tersebut.

� Pengujian hendaknya dilakukan pada setiap tahappengembangan yaitu mulai dari tahap analisis kebutuhansampai dengan tahap perawatan.

KENAPA HARUS DIUJI ?KENAPA HARUS DIUJI ?

� Kita bukan seorang programmer yang cukup baik

� Kita mungkin tidak dapat cukup berkonsentrasi untukmenghindari kesalahan

� Kita terkadang lupa menggunakan pemrogramanterstruktur secara penuh, perancangan atas-bawahterstruktur secara penuh, perancangan atas-bawahuntuk mendapatkan solusi

� Kita kadang buruk dalam mengerjakan sesuatu

KENAPA HARUS DI UJI (2)

� Kita seharusnya dapat membedakan apa yang dikatakanprogrammer lain atau pelanggan dan apa yangsebenarnya mereka pikirkan

� Kita seharusnya merasa bersalah apabila seseorangharus menguji koding kita

� Pengujian merupakan suatu perizinan terhadap� Pengujian merupakan suatu perizinan terhadapkesalahan

PRINSIP PENGUJIAN

Beberapa prinsip pengujian yang harus diperhatikan(diusulkan oleh Davis):1. Semua pengujian harus dapat ditelusuri sampai ke

persyaratan pelanggan.2. Pengujian harus direncanakan lama sebelum2. Pengujian harus direncanakan lama sebelum

pengujian itu dimulai.3. Prinsip Pareto berlaku untuk pengujian PL. Prinsip

Pareto mengimplikasikan 80% dari semua kesalahanyang ditemukan selama pengujian sepertinya akandapat ditelusuri sampai 20% dari semua modulprogram.

4. Pengujian harus mulai "dari yg kecil" dan berkembangke pengujian "yang besar".

5. Pengujian yg mendalam tidak mungkin.6. Paling efektif, pengujian dilakukan oleh pihak ketiga

yang independen

PRINSIP PENGUJIAN (2)

yang independen

SASARAN PENGUJIAN

� Glen Mayers menyatakan sejumlah aturan yang dapat dipandang sebagai sasaran dari pengujian

� Pengujian perangkat lunak adalah suatu prosespengeksekusian program dengan tujuanmenemukan kesalahan (error)

� Pengujian (Test case) yang baik adalah yang

7

� Pengujian (Test case) yang baik adalah yangmempunyai probabilitas yang tinggi untukmenemukan error yang tak diketemukan

� Pengujian yang sukses adalah pengujian yangdapat menemukan kesalahan (error) yang tidakditemukan sebelumnya

TUJUAN PENGUJIANTujuan yang diinginkan dari pelaksanaan pengujianperangkat lunak adalah :� Menilai apakah perangkat lunak yang dikembangkan

telah memenuhi kebutuhan pemakai.� Menilai apakah tahap pengembangan perangkat lunak

telah sesuai dengan metodologi yang digunakan.telah sesuai dengan metodologi yang digunakan.� Membuat dokumentasi hasil pengujian yang

menginformasikan kesesuaian perangkat lunak yangdiuji dengan spesifikasi yang telah ditentukan.

TEST ABILITASTEST ABILITAS

Testabilitas Perangkat Lunak adalah seberapa

mudah sebuah program komputer dapat diuji.

Karena pengujian sangat sulit, perlu diketahui apaKarena pengujian sangat sulit, perlu diketahui apa

yang dapat dilakukan untuk membuatnya menjadi

mudah.

Karakteristik PL yang Di Uji

� OPERABILITASSemakin baik dia bekerja semakin efisien dia dapat diuji.

� OBSERVABILITASApa yang anda lihat adalah apa yang anda uji.

� KONTROLABILITAS� KONTROLABILITASSemakin baik kita dapat mengontrol PL, semakin banyakpengujian yang dapat diotomatisasi dan dioptimalkan.

� DEKOMPOSABILITASDengan mengontrol ruang lingkup pengujian kita dapatlebih cepat mengisolasi masalah dan melakukanpengujian kembali.

� KESEDERHANAANSemakin sedikit yg diuji semakin cepat pengujian.

� STABILITASSemakin sedikit perubahan semakin sedikit gangguanpengujian.

Karakteristik PL yang Di Uji (2)

pengujian.� KEMAMPUAN DIPAHAMI

Semakin banyak informasi yang dimiliki semakin detailpengujiannya.

11

ATRIBUT PENGUJIAN YANG BAIK

� Memiliki probabilitas yg tinggi menemukan kesalahan.� Tidak redundan.� Harusnya ‘jenis terbaik’.� Tidak boleh terlalu sederhana atau terlalu kompleks

DESAIN TEST CASE

Terdapat bermacam-macam rancangan metode test case

yang dapat digunakan, semua menyediakan pendekatan

sistematis untuk uji coba. Yang terpenting metode

menyediakan kemungkinan yang cukup tinggi untuk

menemukan kesalahan.

DESAIN TEST CASE (2)

Terdapat 2 macam test case:

1. Pengetahuan tentang fungsi yang spesifik dari produkyang telah dirancang untuk diperlihatkan, test dapatdilakukan untuk menilai masing-masing fungsi apakahtelah berjalan sebagaimana yang diharapkan.

2. Pengetahuan tentang cara kerja dari produk, test dapatdilakukan untuk memperlihatkan cara kerja dari produksecara rinci sesuai dengan spesifikasinya.

PERANCANGAN TEST CASEPERANCANGAN TEST CASE

DuaDua macammacam pendekatanpendekatan testtest yaituyaitu ::

1.1. BlackBlack BoxBox TestingTesting

TestTest casecase iniini bertujuanbertujuan untukuntuk menunjukkanmenunjukkan fungsifungsiPerangkatPerangkat LunakLunak tentangtentang caracara beroperasinyaberoperasinya,, apakahapakahPerangkatPerangkat LunakLunak tentangtentang caracara beroperasinyaberoperasinya,, apakahapakahpemasukanpemasukan datadata keluarankeluaran telahtelah berjalanberjalan sebagaimanasebagaimanayangyang diharapkandiharapkan dandan apakahapakah informasiinformasi yangyang disimpandisimpansecarasecara eksternaleksternal selaluselalu dijagadijaga kemutakhirannyakemutakhirannya..

2. White Box Testing (Structural Testing)

�� AdalahAdalah meramalkanmeramalkan caracara kerjakerja perangkatperangkat lunaklunaksecarasecara rincirinci,, karenanyakarenanya logikallogikal pathpath ((jalurjalur logikalogika))perangkatperangkat lunaklunak akanakan ditestditest dengandengan menyediakanmenyediakantesttest casecase yangyang akanakan mengerjakanmengerjakan kumpulankumpulan kondisikondisi

PERANCANGAN TEST CASE (2)PERANCANGAN TEST CASE (2)

testtest casecase yangyang akanakan mengerjakanmengerjakan kumpulankumpulan kondisikondisidandan atauatau pengulanganpengulangan secarasecara spesifikspesifik.. SecaraSecarasekilassekilas dapatdapat diambildiambil

�� DijaminDijamin semuasemua independentindependent pathpath ((jalurjalur bebasbebas)) telahtelahdijalankandijalankan setidaknyasetidaknya satusatu kalikali

16Teknik Pengujian Per.Lunak@Berta

WhiteWhite BoxBox ((LanjutanLanjutan))

�� MenjalankanMenjalankan semuasemua keputusankeputusan logislogis padapada sisisisi truetrue &&falsefalse

�� MenjalankanMenjalankan semuasemua loopinglooping

�� MelakukanMelakukan strukturstruktur datadata internalinternal untukuntuk menjaminmenjaminvaliditasvaliditas

PERANCANGAN TEST CASE (3)PERANCANGAN TEST CASE (3)

validitasvaliditas

kesimpulankesimpulan whitewhite boxbox testingtesting merupakanmerupakan petunjukpetunjuk untukuntukmendapatkanmendapatkan programprogram yangyang benarbenar secarasecara 100100%%..


WHITE BOX TESTING1.1. Basis Path TestingBasis Path Testing� Teknik uji coba White Box yang diusulkan Tom Mccabe

(1976). Metode ini memungkinkan perancang test casemendapatkan ukuran kekompleksan logical dariperancangan prosedural dan menggunakan ukuran inisebagai petunjuk untuk mendefinisikan basis set dari jalurpengerjaan.pengerjaan.

� Test case yang didapat digunakan untuk mengerjakanbasis set yang menjamin pengerjaan setiap perintahminimal satu kali selama uji coba. Contoh dari Basis PathTesting :� Notasi Diagram Alir� Cyclomatic Complexity� Graph Metrix

2. Loop Testing� Loop Sederhana

Pengujian loop sederhana dilakukan dgn mudah,dimana n jumlah maksimum yg diijinkan melewatiloop tsb.

WHITE BOX TESTING (2)

loop tsb.1. Lewati loop secara keseluruhan2. Hanya satu yg dapat melewati loop3. m dapat melewati loop dimana m< n

� Loop terangkai� Loop tidak terstruktur

19

� Loop TersarangPengujianPengujian looploop iniini menggunakanmenggunakan pendekatanpendekatan looploopsederhanasederhana.. PetunjukPetunjuk pengujianpengujian looploop tersarangtersarang ::11.. DimulaiDimulai daridari looploop palingpaling dalamdalam.. AturAtur semuasemua looploop keke

nilainilai minimumminimum..


nilainilai minimumminimum..22.. KerjakanKerjakan dgndgn prinsipprinsip looploop sederhanasederhana untukuntuk looploop ygyg

palingpaling dalamdalam sementarasementara tahantahan looploop ygyg didi luarluar padapadaparameterparameter terkecilterkecil ((nilainilai kounterkounter terkecilterkecil))

33.. KemudianKemudian lanjutkanlanjutkan untukuntuk looploop ygyg diatasnyadiatasnya..44.. TeruskanTeruskan sampaisampai semuasemua looploop selesaiselesai didi ujiuji..

� Loop Terangkai

Pengujian loop ini menggunakan pendekatan loopsederhana bila masing-masing loop independen, tetapibila dua loop dirangkai dan pencacah loop 1 digunakansebagai harga awal loop 2 maka loop tsb jadi tidak


sebagai harga awal loop 2 maka loop tsb jadi tidakindependen, maka pendekatan yang diaplikasikan keloop tersarang direkomendasikan.

� Loop Tidak Terstruktur

Kapan saja memungkinkan, loop ini didisain kembaliagar mencerminkan penggunaan komsepsipemrograman tertruktur.

BASIS PATH TESTINGBASIS PATH TESTING

1.1. NotasiNotasi Diagram Diagram AlirAlir (Program Flow Graph)(Program Flow Graph)


BASIS PATH TESTING (BASIS PATH TESTING (22))

�� NotasiNotasi Diagram Diagram AlirAlir (2)(2)

PerancanganPerancangan ProseduralProseduralDalamDalam BentukBentuk FlowchartFlowchart

BASIS PATH TESTING (3)BASIS PATH TESTING (3)

Gambar Grafik Alir

BASIS PATH TESTING (BASIS PATH TESTING (44))

� Lingkaran/node :Menggambarkan satu/lebih perintah prosedural. Urutanproses dan keputusan dapat dipetakan dalam satu node.

� Tanda panah/edge :Menggambarkan aliran kontrol. Setiap node harusmempunyai tujuan nodemempunyai tujuan node

� Region :Adalah daerah yg dibatasi oleh edge dan node.Termasuk daerah diluar grafik alir.

Program Flow Graphs�� MenggambarkanMenggambarkan aluralur kontrolkontrol.. SetiapSetiap cabangcabang ditunjukkanditunjukkan

oleholeh pathpath yangyang terpisahterpisah dandan looploop ditunjukkanditunjukkan oleholeharrowsarrows loopinglooping kembalikembali keke looploop kondisikondisi nodenode..

�� DigunakanDigunakan sebagaisebagai basisbasis untukuntuk menghitungmenghitung cyclomaticcyclomaticcomplexitycomplexity

�� CyclomaticCyclomatic complexitycomplexity�� CyclomaticCyclomatic complexitycomplexity== JumlahJumlah edgesedges –– JumlahJumlah NodeNode ++22

�� CyclomaticCyclomatic complexitycomplexity menyatakanmenyatakan jumlahjumlah testtest untukuntukmengujimenguji controlcontrol statementsstatements

1

2

3

while bottom <= top

if (elemArray [mid] == key

bottom > top

4

65

7

(if (elemArray [mid]< key8

9

Independent PathsIndependent Paths

� 1, 2, 3, 8, 9� 1, 2, 3, 4, 6, 7, 2� 1, 2, 3, 4, 5, 7, 2

1, 2, 3, 4, 6, 7, 2, 8, 9� 1, 2, 3, 4, 6, 7, 2, 8, 9� Test cases harus ditentukan sehingga

semua path tersebut tereksekusi.


� Pendekatan pengujian dimana program dianggapsebagai suatu ‘black-box’ (‘kotak hitam’)

� Program test case berbasiskan spesifikasi� Test planning dapat dimulai sejak awal proses

pengembangan sistem

BLACK BOX TESTINGBLACK BOX TESTING

� Merupakan metode pelengkap White Box Testing.Berfokus pada kebutuhan fungsional dari PL.

� Memungkinkan perancang untuk memperolehsekumpulan kondisi2 input yang secara penuh mengujisemua kebutuhan fungsional suatu program


BLACK BOX TESTING (2) BLACK BOX TESTING (2)

� Metode ini berusaha menemukan kesalahan yangtermasuk kategori di bawah ini� Fungsi2 yg hilang atau tidak benar� Kesalahan pada antarmuka� Kesalahan pada struktur data atau pengaksesan� Kesalahan pada struktur data atau pengaksesan

database ekternal� Kesalahan pada performance� Kesalahan pada inisialisasi dan terminasi

Contoh Black Box Testing adalah

1. Equivalence Partitioning

� Membagi domain input dari program ke dalam klas2data

BLACK BOX TESTING (3) BLACK BOX TESTING (3)

� Input data dan output hasil terdapat di klas yangberbeda yang sesuai dengan klas inputnya

� Masing-masing klas equivalensi partition diprosresdimana program akan memproses anggota klas-klastersebut secara equivale.

� Test cases dipilih dari masing-masing partisi

2. Boundary Value Analysis (BVA)

� Melengkapi Equivalence Partitioning, denganmelakukannya dari domain output BVA merupakanpilihan test case yang mengerjakan nilai yang telahditentukan, dengan teknik perancangan test case

BLACK BOX TESTING (BLACK BOX TESTING (44) )

ditentukan, dengan teknik perancangan test case

� Melengkapi test case equivalence partitioning ygfokusnya pada domain input.


pertemuan 1 pengenalan rekayasa perangkat · pdf fileperawatan (maintenance) ... biaya...

Documents