Penjadwalan dan penelusuran proyek pembangunan PL. ❖ Jaminan ..... PL dan
pengembangan alat bantu, metode, dan teori untuk mendukung produksi PL.
Pertemuan 1 PENGENALAN REKAYASA PERANGKAT LUNAK
Pokok Bahasan dalam RPL :
RPL sebagai produk dan sebagai produk Konsep manajemen proyek Proses pembangunan PL dan metrik proyek 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 Implementasi pembangunan Teknik pengujian perangkat Strategi perancangan PL CASE tool pembangunan PL
Buku Referensi :
• Pressman, RS., 2008, Software Engineering: A Practitioner’s Approach, New York: McGraw-Hill • Sommerville, I, 2007, Software Engineering, Addsion Wesley
Rekayasa Perangkat Lunak
Perangkat Lunak? (Software??) Rekayasa Perangkat lunak-RPL? (Software engineering-SE??) Rekayasa sistem-RS? (system engineering-SyE??) 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 Engineering Terminology, 1990: “Computer programs, procedures, and possibly associated documentation and data pertaining to the operation of a computer system.” Maksudnya : Perangkat lunak merupakan kumpulan dari program, prosedur, dan dokumen data lain yang saling berhubungan yang merepresentasikan masalah di dunia nyata yang dikonfigurasikan dalam sebuah bentuk aplikasi yang harus dikerjakan komputer
Produk Perangkat Lunak Perangkat lunak tidak sama dengan produk perangkat keras Produk perangkat lunak dikembangkan (developed) atau direkayasa (engineered). Sebagian besar dikembangkan atau dibangun berdasrkan pemesanan dan sebagian kecil dibuat secara paket. Tidak dipabrikkan seperti pabrik perangkat keras, misal komputer, mobil. Perangkat lunak secara pemakaian tidak pernah AUS layaknya perangkat keras
Produk Perangkat Lunak (2) 2 Bentuk produk perangkat lunak: 1. Produk Generik (Umum) Sistem stand-alone standar yang diproduksi oleh organisasi pengembang dan dijual ke pasar terbuka ke siapapun yg membelinya. Biasa disebut sebagai software shrink-wrapped. Contoh : word processor, Database. 2. Produk pesanan (yang disesuaikan) Sistem yang dipesan oleh pelanggan tertentu. Dikembangkan khusus bagi pelanggan oleh kontraktor perangkat lunak. Contoh : Sistem untuk mendukung proses bisnis tertentu dan sistem kontrol lalu lintas udara
Produk Perangkat Lunak (3) Perbedaan PENTING antara 2 bentuk perangkat lunak : Pada produk generik, mengembangkan perangkat spesifikasi perangkat lunak.
organisasi yang lunak mengontrol
Pada produk pesanan, spesifikasi biasanya dikembangkan dan dikontrol oleh organisasi yang membeli 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 seperti memory & processor eye cathcing user interface : Mempunyai antarmuka yg menarik long life time : Mempunyai siklus hidup yang cukup lama Mempunyai kinerja sesuai fungsi yang dibutuhkan pemakai
Jenis-jenis aplikasi Perangkat Lunak Perangkat Lunak Sistem (System software) Adalah sekumpulan program yang ditulis untuk melayani atau menunjang program lainnya. Misalnya : compiler, editor, komponen-komponen sistem operasi, driver dan prosesor telekomunikasi. Perangkat lunak waktu nyata (Realtime Software) Perangkat lunak yang berfungsi untuk memonitor, menganalisis, mengontrol dan memberikan laporan tentang kejadian dunia nyata dan meresponnya dalam waktu kurang dari 1 menit. Misal: pengontrol arus udara, pengontrol keasaman tabung reaksi (pressman punya), pengontrol reaksi nuklir, dll
Jenis-jenis aplikasi Perangkat Lunak (2) Perangkat Lunak Teknik Dan (Scientific & Engineering Software)
Ilmu
Pengetahuan
Perangkat lunak yg menangani bidang teknik dan ilmu pengetahuan secara rinci Misal: simulasi astronomi, vulkanologi, analisis otomatif, dinamika orbit pesawat ruang angkasa, biologi molekuler, otomasi pabrik, dll
Embeded System Perangkat lunak yg ditempelkan/dilekatkan pada perangkat lainnya (lunak/keras). Misal: pada kamera digital, GPS, automobil, microwave, kulkas cerdas, dll
Jenis-jenis aplikasi Perangkat Lunak (3) Perangkat Lunak Pengolah Data (Data Processing) Perangkat lunak yg khusus digunakan untuk mengolah data dan menghasilkan suatu keputusan tertentu. Misal: billing telepon, pengolah statistik Perangkat System)
Lunak
Sistem
Informasi
(Information
Perangkat lunak yg mampu memberi informasi dari suatu sistem secara lebih detail. Misal: web site, perpustakaan digital, dll
Jenis-jenis aplikasi Perangkat Lunak (4) Perangkat Lunak Sensor Perangkat lunak yg mampu mengukur dan mengatur suatu keadaan khusus, kadang digolongkan dalam embedded system juga. Misal: pengatur cuaca, pengatur suhu ruangan, dll Perangkat Software)
Lunak
Komunikasi
(Communicaion
Perangkat lunak yg berfungsi untuk menghubungkan atau mengkomunikasikan suatu objek satu dengan lainnya. Misal: router, handphone, dll
Jenis-jenis aplikasi Perangkat Lunak (5) Perangkat Lunak Pengolah Grafis Perangkat lunak yang digunakan untuk melakukan perancangan grafis Misal: pembuatan film, pembuatan poster Perangkat Lunak Kecerdasan Perangkat lunak yg menggunakan algoritma no-numeris untuk memecahkan masalah kompleks yg tdk sesuai untuk 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 mengembangkan praktik dan teknologi dalam meningkatkan produktivitas para praktisi pengembang PL dan kualitas aplikasi yg dapat digunakan oleh pemakai Evolusi dipicu adanya tuntutan bisnis dan lingkungan kerja 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 Didominasi perangkat lunak model custome Munculnya istilah software engineering (akhir 1950an/awal 1960-an) Belum didefinisikan secara jelas tentang aspek– software engineering
Evolusi Perangkat Lunak (3)
Era II (1960 – 1970) Disebut era krisis perangkat lunak (software crisis). Penggunaan perangkat lunak sudah meluas 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 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
Evolusi Perangkat Lunak (5) Era III (1975 – 1985) Pengembangan sistem mengarah ke konsep sistem terdistribusi. Penerapan sistem embeded intelligence Harga perangkat keras sudah jauh lebih murah sehingga pemakaian meluas Pemanfaatan jaringan global dan lokal serta sudah diperkenalkan komunikasi digital
Evolusi Perangkat Lunak (6) Era IV (1985 – 2000) Kemampuan PC sudah setara dengan komputer mainframe Penerapan teknologi yang berorientasi pada objek Implementasi sistem pakar Jaringan saraf tiruan Komputasi paralel Jaringan komputer sudah semakin canggih
Evolusi Perangkat Lunak (7) Era V (2000 – sekarang) Penggunaan media digital Media web berkembang pesat Wireless sudah meluas Teknologi meluas hingga di mobile computing, mobile programming Perangkat keras sudah semakin kecil namun powerfull Dilakukan berbagai penelitian yang menghasilkan model proses/paradigma pengembangan PL utk mengatasi 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 berkembang dalam jumlah besar
yang
ada,
yang
Bagaimana mengimbangi permintaan software yang makin besar.
Mitos Dalam Perangkat Lunak (Management) Mitos1: Kita tidak perlu mengubah pendekatan terhadap pengembangan software, karena jenis pemrograman yang kita lakukan sekarang ini sudah kita lakukan 10 tahun yang lalu. Realitasnya : Walau hasil program sama, produktivitas dan kualitas software harus ditingkatkan dengan menggunakan pendekatan software developments
Mitos Dalam Perangkat Lunak (Management) (2) Mitos2: Kita sudah mempunyai buku yang berisi standarisasi dan prosedur untuk pembentukan software. Realitasnya : Memang buku tersebut ada, tetapi apakah buku tersebut sudah dibaca atau buku tersebut sudah ketinggalan jaman ( out of date ). Mitos3: Jika kita tertinggal dari jadwal yang ditetapkan, kita menambah beberapa programmer saja. Konsep ini sering disebut Mongolian harde concept.
Mitos dalam perangkat lunak (Customer) Mitos1: Pernyataan tujuan umum sudah cukup untuk memulai penulisan program. Penjelasan yang lebih rinci akan menyusul kemudian. Realitasnya : Definisi awal yang buruk adalah penyebab utama kegagalan terhadap usaha-usaha pem-bentukkan software. Penjelasan yang formal dan terinci tentang informasi fungsi performance interface, hambatan desain dan kriteria validasi adalah penting. Karakteristik di atas dapat ditentukan hanya setelah adanya komunikasi antara customer dan developer.
Mitos dalam perangkat lunak (Customer) Mitos2: Kebutuhan proyek yang terus menerus berubah dapat dengan mudah diatasi karena software itu bersifat fleksibel. Realitasnya : memang benar bahwa kebutuhan software berubah, tetapi dampak dari peru-bahan berbeda dari waktu ke waktu.
Mitos Dalam Perangkat Lunak (Praktisi)
Mitos1: Tidak ada metode untuk analisis disain dan testing terhadap suatu pekerjaan, cukup menuju ke depan terminal dan mulai coding. Realitasnya : Metode untuk analisis desain dan testing diperlukan dalam pengembangan software. Mitos2: Segera setelah software digunakan, pemeliharaan dapat diminimalisasikan dan diatasi dengan cara “CATCH AS CATCH CAM”. Realitasnya : Diperlukan budget yang besar dalam maintenance software. Pemeliharaan software harus diorganisir, direncanakan dan dikontrol seolah-olah sebagai suatu proyek besar dalam sebuah organisasi.
Mitos dalam perangkat lunak (Management) Mitos2: Kebutuhan proyek yang terus menerus berubah dapat dengan mudah diatasi karena software itu bersifat fleksibel. Realitasnya : memang benar bahwa kebutuhan software berubah, tetapi dampak dari peru-bahan berbeda dari waktu ke waktu.
Definisi Rekayasa Perangkat Lunak (RPL) RPL atau Software Engineering (SE) Disiplin ilmu yang membahas semua aspek produksi perangkat lunak, mulai dari tahap awal spesifikasi sistem sampai pemeliharaan sistem setelah digunakan. Perangkat Lunak yang dibuat 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 alat bekerja. Menerapkan teori, metode, dan alat bantu yang sesuai, selain itu mereka menggunakannya dengan selektif dan selalu mencoba mencari solusi terhadap permasalahan. 2. “semua aspek produksi perangkat lunak” RPL tidak hanya berhubungan dengan proses teknis dari pengembangan perangkat lunak tetapi juga dengan kegiatan seperti Manajemen proyek PL dan pengembangan alat bantu, metode, dan teori untuk mendukung produksi PL.
Perbedaan RPL dengan Computer science
• Computer science lebih memperhatikan teori & metode komputerisasi, sedangkan software engineering menyangkut masalah praktikal 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 aspek dalam pembangunan sistem berbasis komputer termasuk hardware, rekayasa PL dan proses. RPL adalah bagian dari rekayasa sistem yang meliputi pembangunan PL, infrasktruktur, kontrol, aplikasi dan database pada sistem.
Tantangan dalam Rekayasa Perangkat Lunak Tantangan warisan Dikembangkan bertahun-tahun dengan orang-orang yang berbeda-beda Tantangan heterogensis Dalam hal distribusi & teknologi Tantangan pengiriman Bagaimana mengirim sistem yang besar dan kompleks cepat dan dengan kualitas tetap terjaga.
Pelaku Dalam RPL 1. 2. 3. 4.
Manajer Manajer proyek Manajer konfigurasi Manajer penjamin kulitas PL Manajer bidang lainnya (sesuai kebutuhan
1. 2. 3. 4. 5.
Software Developer Analis sitem Desainer Programmer Inspektor PL Pengontrol perubahan
Pelaku Dalam RPL (Lanjutan) 1. 2. 3. 4. 5.
Pendukung Staf administrasi Humas Pencatat teknis Administrator database Administrator jaringan
Pertemuan 2 SOFTWARE DEVELOPMENT LIFE CYCLE (SDLC)
POKOK BAHASAN Biaya PL Software Quality Attribute Standar 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 PC sering lebih besar dibandingkan dengan harga perangkat kerasnya kec. Di negara-negara yang tidak menghargai HAKI Biaya perangkat lunak secara kasar sebesar 60% dari biaya untuk pembangunan dan 40% untuk pengujian Secara umum besarnya biaya bervariasi tergantung pada tipe sistem yang dibangun dan kebutuhan sistem seperti kinerja dan kehandalan sistem Biaya distribusi tergantung pada model pembangunan yang digunakan
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 (ketersediaannya)
correctness
dan
availability
Sebagai suatu kemungkinan bahwa sistem ini mampu memenuhi suatu kegunaan (tergantung spesifikasinya) untuk sejumlah masukan percobaan di bawah kondisi masukan dan rentang waktu yang telah ditentukan.
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 akhir tahapan Perawatan yang konsisten pada dokumenasi pengembangan Ukuran analitik (analytical measures) Analisis program yang statis Analisis program yang dinamis Pemeilihan test case yang sistematis Pencatatan yang konsisten pada analisis produk
UKURAN JAMINAN KUALITAS (2) Ukuran Organisasi (Organization Measures) Pengalaman pengembang (developer) dalam mempelajari strategi dan teknik yang tepat dalam membangun 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, 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) 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 tingkah laku 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 otomatis dalam aktivitas pembangunan PL. Tujuan meningkatkan produktivitas dalam proses pembangunan PL secara signifikan Dikelompokkan dalam 2 kategori: 1. Upper-CASE Mendukung aktivitas proses pembangunan tahap awal (tahap analisis kebutuhan dan desain) 2. Lower-CASE Mendukung aktivitas pembangunan di tahap akhir programming, debuging, dan testing)
CASE TOOLS (2) 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 Digunakan untuk mencari kesalahan yg mungkin terjadi Automated Translators Digunakan untuk pembangkitan source code program otomatis Compilator Integrated Digunakan membuat antarmuka, koding, hingga membentuk aplikasi yg bisa dijalankan Instalator Kit Digunakan untuk membuat file instalasi/setup
SOFTWARE DEVELOPMENT LIFE CYCLE (SDLC) Proses Generik Spesifikasi Apa yang harus dilakukan oleh perangkat lunak dan batasan/kendala pengembangannya Pengembangan Proses memproduksi sistem perangkat lunak Validasi Pengujian perangkat lunak terhadap keinginan pengguna Evolusi Perubahan perangkat lunak berdasarkan perubahan keinginan.
MODEL PROSES RPL
Model Waterfall, Model Prototyping, Model Evolutionary Model Spiral Reuse Based Development
WATERFALL MODEL Requirement Definitions
Pemodelan Sistem/ Informasi System and software design Implementation and unit testing Integr ation and system testing Operation and maintenance
WATERFALL MODEL (2) Requirements Analysis And Definition Pembentukan kebutuhan System And Software Design Mengubah kebutuhan-kebutuhan menjadi karakteristik yang dimerngerti perangkat lunak Implementation And Unit Testing Penulisan program Integration And System Testing Memeriksa program, mencari kesalahan Operation And Maintenance Pemeliharaan sistem, menambahkan fungsi
bentuk
WATERFALL MODEL (3) Problems Model Waterfall 1. Jarang sekali proyek yang prosesnya bisa dilakukan secara sequencial. 2. Sukar bagi customer untuk secara mengemukakan semua kebutuhannya.
explisit
3. Customer harus sabar. 4. Developer sering menunda pekerjaan. Anggota tim harus menunggu anggota lainnya 5. menyelesaikan tugasnya.
PROTOTYPE MODEL Membangun Konstruksi (prototipe)
Mendengarkan Pelanggan
Uji Pelanggan (evaluasi)
PROTOTYPE MODEL (2) Prototype Paradigm dimulai dengan mengumpulkan kebutuhan-kebutuhan customer. Developer dan customer bertemu dan mendefinisikan obyektif software secara menyeluruh, mengidentifikasi kebutuhan-kebutuhan yang diketahui dari area pekerjaan. Setelah itu dibuat Quick Design. Quick Design difokuskan pada representasi aspek software yang bisa dilihat customer/user (misal: format input dan output). Quick Design cenderung ke pembuatan prototipe. Prototipe dievaluasi customer/user dan digunakan untuk menyempurnakan kebutuhan software yang akan dikembangkan.
PROTOTYPE MODEL (2) Sering terjadi customer menjabarkan objektif umum mengenai software yang diminta, tetapi tidak bisa mendefinisakan input, proses, output yang diminta secara detail. Disisi lain, developer menjadi tidak yakin terhadap efisiensi algoritma, kemampuan adaptasi terhadap sistem operasi, atau bentuk interaksi mesin dengan orang. Untuk mengatasi situasi tersebut, bisa digunakan pendekatan 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 bisa berjalan. Development membuat implemetasi yang kompromitas dengan tujuan untuk memperoleh prototipe pekerjaan secara cepat. Dampaknya adalah sistem operasi atau bahasa pemrograman yang dipergunakan tidak tepat, algoritma tidak efisien.
EVOLUTIONARY MODEL
EVOLUTIONARY MODEL INCREMENTAL (2) Penjelasan : 1. Kombinasikan elemet-element dari waterfall dengan sifat iterasi/perulangan. 2. Element-element dalam waterfall hasil berupa produk dengan
dikerjakan
dengan
3. Spesifikasi tertentu, kemudian proses dimulai dari fase pertama hingga akhir dan menghasilkan produk dengan spesifikasi yang lebih lengkap dari yang sebelumnya. 4. Demikian seterusnya hingga semua spesifikasi memenuhi kebutuhan yang ditetapkan oleh pengguna.
EVOLUTIONARY MODEL INCREMENTAL (3) 5. Produk hasil increment pertama biasanya produk inti (core product), yaitu produk yang memenuhi kebutuhan dasar. Produk tersebut digunakan oleh pengguna atau menjalani review/ pengecekan detil. Hasil review tersebut menjadi bekal untuk pembangunan pada increment berikutnya. Hal ini terus dikerjakan sampai 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 bisa berfungsi dengan spesifikasi dasar.
EVOLUTIONARY MODEL INCREMENTAL (4) Kekurangan Incremental Model: Hanya cocok untuk proyek berukuran kecil (tidak lebih dari 200.000 baris coding) Mungkin terjadi kesulitan untuk memetakan kebutuhan pengguna ke dalam rencana spesifikasi masingmasing hasil increment
EVOLUTIONARY MODEL SPIRAL
EVOLUTIONARY MODEL SPIRAL (2) Penjelasan : Customer Comunication Membangun komunikasi yang baik dengan pelanggan Planning Mendefinisikan sumber, batas waktu, informasi-informasi lain seputar proyek Risk Analyst 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 fase engineering dan fase instalasi
EVOLUTIONARY MODEL SPIRAL (3) Pada model spiral, resiko sangat dipertimbangkan. Resiko adalah sesuatu yang mungkin mengakibatkan kesalahan. Model spiral merupakan pendekatan yang realistik untuk Perangkat Lunak berskala besar. Pengguna dan pembangun bisa memahami dengan baik software yang dibangun karena setiap kemajuan yang dicapai selama proses dapat diamati dengan baik. Namun demikian, waktu yang cukup panjang mungkin bukan pilihan bagi pengguna, karena waktu yang lama sama dengan biaya yang lebih besar.
REUSE BASED A. Software Re-engineering Apakah itu? Restrukturisasi atau menulis ulang sebagian atau keseluruhan dari sistem yang telah ada tanpa merubah fungsionalitasnya. Kapan? Ketika sebagian tetapi tidak semua sub sistem yg besar membutuhkan perawatan yg sering Ketika HW dan SW sudah lama hampir tak berfungsi Bagaimana? Sistem bisa di restrukturisasi dan didokumentasi ulang untuk membuat menjadi mudah dalam perawatan
REUSE BASED (2) Software Re-engineering (lanjutan) Mengapa? Mengurangi resiko SW yang baru dibangun membawa resiko yg tinggi Mengurangi biaya Biaya untuk re-engineering sering lebih kecil dibanding membangun SW baru.
REUSE BASED (3)
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 Mengapa? Kode aslinya telah dalam keterbatasan dimana sudah terlalu lama, misal kebutuhan memori, kinerja, dll Perawatan terbentur pada struktur dan program yang rusak sehingga membutuhkan kerja yg sangat keras Program secara otomatis distrukturisasi ulang untuk menghilangkan beberapa bagian yang tidak beres dalam kondisi yang sangat kompleks.
Pertemuan 3 Manajemen Proyek Perangkat Lunak
Proses Dalam Manajemen PL Manajemen proyek merupakan lapisan pertama dalam proses rekayasa perangkat lunak skala besar. Untuk menuju pada proyek yang berhasil, perlu dimengerti tentang : Lingkup pekerjaan Resiko yang dapat ditimbulkan Sumber-sumber yang diperlukan Tugas yang harus dilaksanakan Patokan yang harus diikuti Usaha atau biaya yang dikeluarkan Dan Penjadwalan
Langkah Awal dalam Manajemen Perangkat Lunak Untuk
mengestimasi
biaya,
pembagian
tugas,
penjadwalan, sebelum sebuah proyek direncanakan : Memastikan tujuan dan ruang lingkup Memperhatikan alternatif-alternatif solusi Identifikasi batasan teknik dan manajerial
dan
Fokus Manajemen Proyek Manajemen proyek terfokus pada 4P, yaitu : 1. People Elemen terpenting dalam keberhasilan suatu proyek 2. Product Perangkat lunak yang dihasilkan 3. Process Sekelompok aktivitas kerangka kerja dalam merekayasa perangkat lunak 4. Project Seluruh proses yang dibutuhkan untuk menghasilkan suatu produk
Faktor-faktor yang mempengaruhi hasil akhir proyek Perangkat Lunak Ukuran (size) Batas waktu pengiriman (Delivery Deadline) Pembiayaan dan anggaran (Budgets & Costs) Bidang aplikasi (Application Domain) Implementasi Teknologi (Technology Can Be Implemented) 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 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 yang diinginkan bersama Manajemen Sumber Daya Manusia
Pengukuran Perangkat Lunak Pengukuran dan satuan ukuran akan membantu untuk mengerti proses-proses dalam pengembangan dan produk itu sendiri. Proses dan produk diukur untuk meningkatkan kualitasnya.
usaha
Pengukuran Perangkat Lunak (2) 1. Pengukuran Langsung Terkait dengan biaya dan usaha yang diaplikasikan, misalnyayang menyangkut deretan kode program, kecepatan eksekusi, ukuran memori yang dibutuhkan dan cacat pada produk, yang dilaporkan pada sejumlah periode waktu 2. Pengukuran tidak Langsung Terkait dengan fungsionalitas, kualitas, kompleksitas, efisiensi, reabilitas, kemampuan pemeliharaan dan lainlain
Pengukuran Perangkat Lunak (3) Mengapa perangkat Lunak Harus Diukur?? 1. Untuk mengetahui karakteristik Perangkat Lunak 2. Proses evaluasi Perangkat Lunak 3. Prediksi kebutuhan Perangkat Lunak 4. Pengembangan Perangkat Lunak
Pengukuran Perangkat Lunak (4) 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)
Estimasi Dalam aktifitas dilakukan:
utama
proyek
yaitu
perencanaan,
Sumber daya manusia (ukuran orang/bulan) 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 membiayai proyek Untuk mengontrol dan mendokumentasikan pembiayaan 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 dengan metode TCA Terkonsentrasi pada biaya tidak langsung (tambahan) Biaya selalu berhubungan dengan aktifitas Aktifitas selalu menggunakan sumber daya Mengkonversi biaya langsung menjadi tidak langsung
Analisis Resiko Analisis resiko merupakan serangkaian langkah untuk menyiasati resiko Analisis resiko sangat penting dalam manajemen proyek perangkat lunak. Beberapa hal yang harus diperhatikan berkaitan dengan resiko adalah: Masa yang akan datang, Perubahan, Pilihan.
Menyiasati Resiko
Identifikasi resiko Melihat semua resiko sesuai dengan kategori(secara makro). Perkiraan resiko Memperhitungkan lebih lanjut estimasi resiko. Proyeksi resiko Disebut juga estimasi resiko, adalah usaha untuk mengukur setiap resiko. Strategi manajemen resiko Putusan (Resolution) resiko Pemantauan resiko
Pengendalian Resiko Strategi Penanganan Resiko 1. Manajemen Resiko Reaktif Tim proyek beraksi pada resiko mereka menjumpainya Pelonggaran rencana penambahan resource antisipasi, misalnya kebakaran Perbaikan pada kesalahan, sumber daya yang ditemukan & diterapkan ketika resiko sudah menyerang Manejemen krisis kesalahan tidak dapat direspon oleh sumber daya & menjadi ancaman bagi keberlangsungan proyek
Pengendalian Resiko (2) 2.
Manajemen Resiko Proaktif Kinerja analisis resiko secara formal Koreksi terorganisasi pada penyebab resiko Pengujian sumber resiko yang diantaranya adalah perangkat lunak Pengembangan kemampuan untuk mengatur perubahan
Perencanaan Proyek Memahami masalah yang akan di hadapi Menentukan cara-cara yang tepat untuk mendapatkan solusi yang tepat Pengoptimalan efisiensi dan keuntungan proyek Memerlukan dokumen kebutuhan yang akan digunakan untuk pengambilan keputusan menerima proyek/menolaknya. Jika menerima maka langkah selanjutnya adalah membuat proposal
Perencanaan Proyek (2) Segitiga proyek (Proyek Triangle) 1. Time Penjadwalan tugas, penentuan ketergantungan tugas 2. Money Anggaran Belanja, sumber daya 3. Scope Ruang lingkup pekerjaan
durasi,
Perencanaan Proyek (3) Strategi Perencanaan memilih dan menerapkannya Hasil tujuan Asumsi/anggapan Pembatasan Area/cakupan berhubungan dengan tugas dan 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
Perencanaan Proyek (4) 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)
Penjadwalan Langkah-langkah yang dilakukan dalam penjadwalan: 1. Identifikasi sekumpulan tugas 2. Pastikan keterkaitan antar tugas 3. Estimasi usaha untuk tiap-tiap tugas 4. Tentukan pekerja dan sumber-sumber lainnya 5. Buat jaringan tugas 6. Buat jadwal kerja berdasarkan waktu
Penelusuran dan Pengendalian Penelusuran
dan
pengendalian
dilakukan
setelah ada penjadwalan yang pasti, yaitu memeriksa apakah tugas telah dilaksanakan sesuai dengan jadwal.
Tujuan Pengukuran Perangkat Lunak Indikasi kualitas produk Perkiraan produktivitas menghasilkan produk
orang-orang
yang
Perkiraan manfaat dari penerapan metode dan tools Membentuk dasar dari estimasi Menegaskan (Justify) permintaan tools baru dan pelatihan
Ukuran Kualitas Perangkat Lunak Kualitas perangkat lunak dihitung pada saat proses rekayasa perangkat lunak ataupun setelah diserahkan kepada pemakai. Satuan ukuran kualitas perangkat lunak pada saat 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 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 pengaruh penting dalam proyek Manager (Teknis) Proyek Merencanakan, memotivasi, mengorganisir mengontrol proyek sebuah produk / aplikasi
dan
Pelaksana Yang menyampaikan keterampilan teknik yang diperlukan untuk merekayasa sebuah produk / aplikasi
Komponen Dalam Proyek PL (2) Pelanggan Menentukan jenis kebutuhan akan perangkat lunak yang akan direkayasa Pemakai Akhir (end-user) Yang berinteraksi dengan perangkat lunak bila perangkat lunak telah dipublikasikan (release) untuk digunakan
Komponen Dalam Proyek PL (3) Faktor yang harus dipertimbangkan dalam menyeleksi tim pelaksana proyek 1. Tingkat kesulitan dari masalah yang akan dikerjakan 2. Ukuran program yang dihasilkan yang terkait dengan jumlah fungsi yang digunakan 3. Waktu yang dibutuhkan oleh tim untuk bekerja secara bersama-sama 4. Tingkatan dimana masalah dapat dimodularisasi / dibuat dalam bentuk modul
Komponen Dalam Proyek PL (4) 5. Kualitas yang diperlukan serta keandalan sistem yang dibangun 6. Kepastian tanggal penyampaian ke pelanggan 7. Memiliki kemampuan sosialisasi (komunikasi) yang dibutuhkan dalam proyek
Definisi Masalah dalam RPL 1. Menetapkan Ruang Lingkup Permasalahan : Konteks Bagaimana software yang akan dibangun nantinya dapat memenuhi kebutuhan sistem serta batasan yang ditentukan oleh sistem Tujuan Informasi Menentukan objek data yang dihasilkan sebagai output dan object data yang diperlukan sebagai input Fungsi dan Unjuk Kerja Menentukan fungsi yang akan dilakukan untuk mentransformasi input data menjadi output serta ciri kerja khusus yang akan ditekankan
Definisi Masalah dalam RPL (2) 2. Dekomposisi masalah Menetapkan pembagian fungsi / aktivitas kerja pada 2 area utama, yaitu ; Fungsionalitas yang harus disampaikan Proses yang akan dipakai untuk menyampaikannya
ARTIFACT UML Use-Case Diagram
Class Diagram
State Diagram
Document add( ) delete( )
name : int docid : int numField : int get( ) open( ) close( ) read( ) sortFileList( ) create( ) fillDocument( )
FileList
Use Case 1
fList add( ) delete( )
Actor A
Writing
add file [ numberOffile==MAX ] / flag OFF
read() fill the code..
Openning
close file
1
Actor B close file Reading
Closing
rep
Use Case 2
File
Repository (from Persistence)
read( )
Customer name addr receive() withdraw() fetch() send()
Use Case Use Case Diagrams Use Case Diagrams Diagrams
State State Diagrams Class Diagrams Diagrams
Model
Deployment Diagram
State State Diagrams Object Diagrams Diagrams
State State Diagrams State Diagrams Diagrams
Component Component Diagrams Component Diagrams
Diagrams
USE CASE DIAGRAM • Menggambarkan fungsionalitas yang diharapkan dari sebuah sistem. Yang ditekankan adalah “apa” yang diperbuat sistem, dan bukan “bagaimana”. • Menggambarkan kebutuhan system dari sudut pandang user • Mengfokuskan pada proses komputerisasi (automated processes) • Menggambarkan hubungan antara use case dan actor
• Use case menggambarkan proses system (kebutuhan system 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 a. Use case b. Actors c. Relationship d. System boundary boxes (optional) e. Packages (optional)
Deskripsi Use case Diagram Use case • Use case dibuat berdasar keperluan actor, merupakan “apa” yang dikerjakan system, bukan “bagaimana” system mengerjakannya • Use case diberi nama yang menyatakan apa hal yang 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 informasi dari system • Actor menggambarkan sebuah tugas/peran dan bukannya posisi sebuah jabatan • Actor memberi input atau menerima informasi dari system • Actor biasanya menggunakan Kata benda Simbol actor
• Tidak boleh ada komunikasi langsung antar actor • Indikasi untuk sebuah actor yang merupakan sebuah system • Adanya actor bernama “Time” yang mengindikasikan scheduled events (suatu kejadian yang terjadi secara periodik/bulanan) • Letakkan actor utama anda pada pojok kiri atas dari diagram
Association • • •
Associations bukan menggambarkan aliran data/informasi Associations digunakan untuk menggambarkan bagaimana actor terlibat dalam use case Ada 4 jenis relasi yang bisa timbul pada use case diagram 1. Association antara actor dan use case 2. Association antara use case 3. Generalization/Inheritance antara use case 4. Generalization/Inheritance antara actors
Association antara actor dan use case • Ujung panah pada association antara actor dan use case mengindikasikan siapa/apa yang meminta interaksi dan bukannya mengindikasikan aliran data • Sebaiknya gunakan Garis tanpa panah untuk association antara actor dan use case • association antara actor dan use case yang menggunakan panah terbuka untuk mengindikasikan bila actor berinteraksi secara pasif dengan system anda
Association antara use case • 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 Register for courses Logon validation
Maintain curriculum
Association antara use case (Lanjut) • perluasan dari use case lain jika kondisi atau syarat terpenuhi – 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
Buka Rekening Nasabah
Buka Deposito
Generalization/inheritance antara use case • Generalization/inheritance digambarkan dengan sebuah garis berpanah tertutup pada salah satu ujungnya yang menunjukkan lebih umum • Gambarkan generalization/inheritance antara use case secara vertical dengan inheriting use case dibawah base/parent use case • Generalization/inheritance dipakai ketika ada sebuah keadaan yang lain sendiri/perlakuan khusus (single condition) Buka Rekening
Nasabah
Buka Deposito
Generalization/inheritance antara actor • Gambarkan generalization/inheritance antara actors secara vertical dengan inheriting actor dibawah base/parent use case
Use case System boundary boxes • Digambarkan dengan kotak disekitar use case, untuk menggambarkan jangkauan system anda (scope of of your system). • Biasanya digunakan apabila memberikan beberapa alternative system yang 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 dari pengembangan dan desain berorientasi objek. • Class menggambarkan keadaan (atribut/properti) suatu sistem, sekaligus menawarkan layanan untuk memanipulasi keadaan tersebut (metoda/fungsi). • Class diagram menggambarkan struktur dan deskripsi class, package dan objek beserta hubungan satu sama lain seperti containment, pewarisan, asosiasi, dan lain-lain. • Class memiliki tiga area pokok : 1.Nama, merupakan nama dari sebuah kelas 2. Atribut, merupakan peroperti dari sebuah kelas. Atribut melambangkan batas nilai yang mungkin ada pada obyek dari class 3. Operasi, adalah sesuatu yang bisa dilakukan oleh sebuah class atau yang dapat dilakukan oleh class 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 sama Nama Class Atribut Metode/operasi
HUBUNGAN ANTAR CLASS 1. Asosiasi, yaitu hubungan statis antar class. Umumnya menggambarkan class yang memiliki atribut berupa class lain, atau class yang harus mengetahui eksistensi class lain. Panah navigability menunjukkan arah query antar class. 2. Agregasi, yaitu hubungan yang menyatakan bagian (“terdiri atas..”). 3. Pewarisan, yaitu hubungan hirarkis antar class. Class dapat diturunkan dari class lain dan mewarisi semua atribut dan metoda class asalnya dan menambahkan fungsionalitas baru, sehingga ia disebut anak dari class yang diwarisinya. Kebalikan dari pewarisan adalah generalisasi. 4. Hubungan dinamis, yaitu rangkaian pesan (message) yang di-passing dari satu class kepada class lain. Hubungan dinamis dapat digambarkan dengan menggunakan sequence diagram yang akan dijelaskan kemudian.
CONTOH CLASS DIAGRAM
MULTIPLICITY • Unspecified • Exactly one • Zero or more (many, unlimited)
1 0..* *
• • • •
One or more Zero or one (optional scalar role) Specified range Multiple, disjoint ranges
1..* 0..1 2..4 2, 4..6
Class Diagram diperoleh berdasarkan dari database Contoh Kasus (Acknowledgments Evi Lutfi Muktar)
modul id_modul int(5) nama_modul varchar(50) link varchar(100) static_content text gambar varchar(100) publish enum('Y','N') status enum('user','admin','umum') aktif enum('Y','N') urutan int(5) simpan() batal()
1
user id_user varchar(50) password varchar(50) nama_lengkap varchar(100) email varchar(100) 1 bagian varchar(100) referensi varchar(100) level varchar(50)
master_tarif nomor int(5) peruntukan varchar(10) tarif varchar(2) daya varchar(10) bp int(10) ujl int(10) materai int(10)
simpan() batal()
keluhan_pelanggan id int(5) nomor_pelanggan varchar(12) nama_pelanggan varchar(20) email varchar(100) keluhan text kode_security varchar(6)
• Statechart diagram, atau yang biasa juga disebut state diagram digunakan untuk mendokumentasikan beragam kondisi/keadaan yang bisa terjadi terhadap sebuah class dan kegiatan apa saja yang dapat merubah kondisi/keadaan tersebut. Contohnya sebuah televisi yang dapat berada dalam kondisi menyala atau mati, jika tombol “power” ditekan maka televisi akan menyala, begitu juga sebaliknya akan mati jika tombol “power” ditekan kembali. Maka disini kita mempunyai sebuah kelas yaitu televisi, 2 state yaitu menyala dan mati dan 2 transition yaitu menyalakan TV dan mematikan TV. Tidak seperti diagram-diagram behavioural lainnya yang memodelkan interaksi diantara beberapa class, state diagram justru biasanya hanya memodelkan transisi yang terjadi hanya pada sebuah class. Berikut adalah notasi state diagram :
State
Transition
Notasi State menggambarkan kondisi sebuahentitas, dan digambarkan dengan segiempat yang pinggirnya tumpul dengan nama state didalamnya
Sebuah Transition menggambarkan sebuah perubahan 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
Initial State
sebuah kondisi awal sebuah object sebelum ada perubahan keadaan. Initial State digambarkan dengan sebuah lingkaran solid. Hanya satu Initial State yang diizinkan dalam sebuah diagram
Final State
menggambarkan ketika objek berhenti memberi respon terhadap sebuah event. Final State digambarkan dengan lingkaran solid didalam sebuah lingkaran kosong.
State1 State1
Transition
• Statechart diagram menggambarkan transisi dan perubahan keadaan (dari satu state ke state lainnya) • suatu objek pada sistem sebagai akibat dari stimuli yang diterima. Pada umumnya statechart • diagram menggambarkan class tertentu (satu class dapat memiliki lebih dari satu statechart • diagram). • 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” states is state has transitions into it but none out – Miracle states is state has transitions out of it but none into it • initial state / creation state dengan tanda Untuk memulai sebuah state machine diagram (in western culture people read from left to right, top to bottom, starting in the top-left corner) • Final state dengan tanda Untuk mengakhiri sebuah state machine diagram Letakkan pada pojok kanan bawah(in western culture people read from left to right, top to bottom, starting in the top-left corner) • Simple State Sebuah State yang tidak mempunyai Sub States/region/submachines
State Machine Diagram (Statechart diagram in versi 1.x) State 1 • Composite State – Digunakan untuk – Kumpulan dari mendukung konsep beberapa states State 2 State 3 encapsulation yang setidaknya – Sebuah state tidak boleh dalam sebuah mempunyai region dan region submachine secara – Orthogonal State, bersamaan jenis composite – Nama state mempunyai state lebih dari 1 sintaks : region nama submachine state : • 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
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 bersamaan 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
State Machine Diagram (Statechart diagram in versi 1.x)
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 format event [guard][/methode list()]
• • • •
event biasa dituliskan dengan past tense 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: X0 konsisten X=0 tidak konsisten • Guards harus lengkap logikanya Contoh: X0 , 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
State Machine Diagram (Statechart diagram in versi 1.x) • Join, menggabungkan beberapa transition menjadi sebuah transition • Fork, memecah sebuah transition menjadi beberapa transition yang berkondisi AND (transition harus dilewati semuanya). • Junction, Menggabungkan sebuah/beberapa transition dan memecahnya menjadi sebuah/beberapa transition yang berkondisi AND (transition harus dilewati semuanya). Digunakan tanda lingkaran hitam kecil Contoh:
• Dimungkinkan transition ke sebuah state yang berisi beberapa state yang disebut state list State1, State2
State Machine Diagram (Statechart diagram in versi 1.x) • 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 point Dilambangkan sebuah lingkaran kecil yang ditaruh pada pinggiran state(bisa juga didalam atau diluar), dan berguna sebagai submachine state
• Exit point Dilambangkan sebuah lingkaran kecil bersilang yang ditaruh pada pinggiran state (bisa juga didalam atau diluar), dan berguna sebagai submachine 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 dan perubahan keadaan (dari satu state ke state lainnya) suatu objek pada sistem sebagai akibat dari stimuli yang diterima. • Pada umumnya statechart diagram menggambarkan class tertentu (satu class dapat memiliki lebih dari satu statechart diagram). • Dalam UML, state digambarkan berbentuk segi empat 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 State Diagram
Deployment Diagram • Deployment/physical diagram menggambarkan detail bagaimana komponen di-deploy dalam infrastruktur sistem, di mana komponen akan terletak (pada mesin, server atau piranti keras apa), bagaimana kemampuan jaringan pada lokasi tersebut, spesifikasi server, dan halhal lain yang bersifat fisikal • Sebuah node adalah server, workstation, atau piranti keras lain yang digunakan untuk men-deploy komponen dalam lingkungan sebenarnya. Hubungan antar node (misalnya TCP/IP) dan requirement dapat juga didefinisikan dalam diagram ini.
Component Diagram • Component diagram menggambarkan struktur dan hubungan antar komponen piranti lunak, termasuk ketergantungan (dependency) di antaranya. • Komponen piranti lunak adalah modul berisi code, baik berisi source code maupun binary code, baik library maupun executable, baik yang muncul pada compile time, link time, maupun run time. • Pada umumnya komponen terbentuk dari beberapa class dan/atau package, tapi dapat juga dari komponenkomponen yang lebih kecil. • Komponen dapat juga berupa interface, yaitu kumpulan layanan yang disediakan sebuah komponen untuk komponen lain.
Contoh : Component Diagram
Demo.html
applet1.class
applet1.java
applet2.class
applet2.java
logo.gif
Contoh : Component & Deployment Diagram
Contoh kasus (Acknowledgments Toeko triyanto)
state chart diagram pendaftaran
pengisian data
kirim
statechart diagram pengisian data kwitansi.
isi ulang
data masukan simpan
pengisian data
kirim
isi ulang
data masukan simpan
ACTIVITY DIAGRAM • Menggambarkan proses bisnis dan urutan aktivitas dalam sebuah proses • Dipakai pada business modeling untuk memperlihatkan urutan aktifitas proses bisnis • Struktur diagram ini mirip flowchart atau Data Flow Diagram pada perancangan terstruktur • Sangat bermanfaat apabila kita membuat diagram ini terlebih dahulu dalam memodelkan sebuah proses untuk membantu memahami proses secara keseluruhan • Activity diagram dibuat berdasarkan sebuah atau beberapa use case pada use case diagram
Simbol Activity Diagram Simbol
Keterangan Start Point End Point Activities
Fork (Percabangan)
Join (Penggabungan)
Decision
Swimlane
Sumber : Rational rose
Sebuah cara untuk mengelompokkan activity berdasarkan Actor (mengelompokkan activity dalam sebuah urutan yang sama)
CONTOH ACTIVITY DIAGRAM
Penarikan Uang dari Account Bank Melalui ATM
CONTOH ACTIVITY DIAGRAM Bagian Gudang
Memberi informasi data Barang yang akan dipesan
Bagian Pembelian
Menerima informasi
Buat SPP
Terima SPP
Kirim Barang disertai Faktur
Terima Barang dan Faktur
Buat SPBJ
Supplier
Tandatangani SPBJ
Melakukan pembayaran
Terima SPBJ
Konfirmasi pembayaran
Terima pembayaran
Terima Kwitansi
Buat kwitansi
Procedure Berjalan (Acknowledgments Evi Lutfi Muktar) Proses pembuatan Daftar Data Pegawai dan Gaji pada SMP PGRI 1 Depok adalah sebagai berkut : 1. Proses Absensi Pegawai melakukan absensi harian melalui form daftar hadir pegawai. Berdasarkan form daftar hadir pegawai tersebut bagian Tata Usaha (TU) akan membuat Rekap Absen (RA) harian untuk diserahkan kepada Administrasi. 2. Proses Pemberian Rekap Biodata Pegawai (RBP) Pegawai memberikan data pribadi pegawai, data pendidikan, data keluarga yang dijadikan satu menjadi data pegawai kepada bagian Tata Usaha yang kemudian diarsipkan menjadi Rekap Biodata Pegawai (RBP). Lalu Rekap Biodata Pegawai (RBP) diserahkan kepada bagian administrasi untuk proses pengolahan Daftar Data Pegawai Dan Gaji (DDPG).
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 untuk dibuatkan menjadi Daftar Data Pegawai dan Gaji (DDPG) yang kemudian diserahkan kepada Kepala Sekolah untuk ditanda tangani atau di Acc. 3.
4.
Proses Pembuatan Laporan Daftar Data Pegawai dan Gaji (DDPG) yang sudah diterima dan ditanda tangani oleh Kepala Sekolah akan diserahkan kembali kepada bagian Administrasi untuk dibuatkan Laporan Data Pegawai (LDP) dan Laporan Gaji Pegawai (LGP). Setelah bagian administrasi menerima Daftar Data Pegawai dan Gaji yang sudah di Acc akan membuatkan Laporan Data Pegawai (LDP) dan Laporan Gaji Pegawai (LGP) yang nantinya akan diserakan kepada Kepala Sekolah.selain itu bagian Administrasi akan membuatkan slip gaji 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 pada PT PLN adalah sebagai berikut : •Pendaftaran perubahan daya Konsumen datang kekantor PT PLN(Persero) dengan membawa fotocopy KTP dan kwitansi pembayaran rekening bulan terakhir kemudian diserahkan dibagian pelayanan pelanggan. Pegawai pelayanan pelanggan akan menginput berdasarkan data dari konsumen , setelah diinput maka akan dicetak formulir pendaftaran perubahan daya untuk kemudian ditandatangani oleh pelanggan. Satu rangkap untuk pelanggan sebagai tanda bukti. Lainnya disimpan oleh bagian pelayanan pelanggan untuk diteruskan ke supervisor untuk proses persetujuan
Activity diagram pendaftaran perubahan daya
pelanggan
pelayanan pelanggan
memberikan fotocopy ktp dan rekening listrik
menerima fotocopy ktp dan rekening listrik
spv pelayanan
input pendaftaran pelanggan
cetak formulir pendaftaran
menerima formulir pendaftaran
memberikan formulir pendaftaran
menyetujui formulir pendaftaran
memberikan formulir pendaftaran
menerima formulir pendaftaran
memberikan formulir pendaftaran
menerima formulir pendaftaran
• Persetujuan perubahan daya Rangkap formulir pendaftaran yang disimpan oleh bagian pelayanan pelanggan kemudian dibuatkan surat jawaban persetujuan yang kemudian ditandatangani oleh supervisor pelayanan pelanggan dicetak menjadi dua rangkap, rangkap pertama diberikan kepada pelanggan , sedangkan rangkap yang kedua disimpan oleh bagian pelayanan pelangan sebagai arsip. pelayanan pelanggan
memberikan formulir pendaftaran
spv pelayanan
pelanggan
menerima formulir pendaftaran
membuat surat persetujuan
menyetujui surat persetujuan
memberikan surat persetujuan
menerima surat persetujuan
• Perjanjian jual beli tenaga listrik Setelah pelanggan menerima surat jawaban persetujuan dari PT. PLN (Persero) maka sipelanggan akan datang ke kantor PT PLN untuk menandatangani surat perjanjian jual beli tenaga listrik sesuai dengan daya listrik yang baru yang akan dipasang. Surat perjanjian jual beli tenaga listrik tersebut juga ditandatangani oleh manager. pelanggan
menerima surat persetujuan
spv pelayanan
manager
membuat surat perjanjian jual beli tenaga listrik
mencetak surat perjanjian jual beli tenaga listrik
m emberikan surat perjanjian jual beli tenaga listrik
menerima surat perjanjian jual beli tenaga listrik
menyetujui surat perjanjian jual beli tenaga listrik
menerima surat perjanjian jual beli tenaga listrik
menerima surat perjanjian jual beli tenaga listrik
memberikan surat perjanjian jual beli tenaga listrik
menyetujui surat perjanjian jual beli tenaga listrik
m emberikan surat perjanjian jual beli tenaga listrik
m enerim a surat perjanjian jual beli tenaga listrik
memberikan surat perjanjian jual beli tenaga listrik
• Pembayaran Setelah menandatangani surat perjanjian jual beli tenaga listrik maka sipelanggan tinggal membayar sejumlah yang tertera pada surat perjanjian jual beli tenaga listrik ke loket pembayaran perubahan daya, pelanggan akan mendapatkan kwitansi pembayaran sebagai bukti bahwa si pelanggan telah melaksanakan kewajibannya. pelanggan
melakukan pembayaran
loket PTPLN
menerima pembayaran
cetak bukti pembayaran
menyetujui bukti pembayaran
menerima bukti pembayaran
memberikan bukti pembayaran
• Perintah kerja Saaat si pelanggan membayar kewajibannya maka perintah kerja terbit dan siap untuk di cetak, untuk diberikan kepada pelaksana sebagai perintah kerja untuk pelanksanaan penggantian MCB pelanggan. bagian penyam bungan
pelaksana
pelanggan
cetak perintah kerja
m enyetujui perintah kerja
m elakukan penggantian MCB
menerim a perintah kerja
melakukan penggantian MCB
memberikan perintah kerja
m enerima perintah kerja
menyetujui perintah kerja
menerima perintah kerja
menerim a perintah kerja
memberikan perintah kerja
memberikan perintah kerja
Latihan STUDI KASUS ACTIVITY DIAGRAM • Koperasi STMIK Nusa Mandiri adalah sebuah koperasi yang mengelola simpan pinjam bagi para anggotanya, berikut ini adalah kegiatan yang dilakukan oleh bagian Kredit dalam menangani pemberian pinjaman bagi para anggotanya. • Setiap kali bagian kredit akan memberikan pinjaman kepada Anggota maka Anggota diharuskan mengisi Formulir Permohonan Pinjaman yang berisi Nomor FPP, Tanggal Permohonan, Nomor Anggota, Nama Anggota, Jumlah Permohonan dan Keperluan. Yang kemudian oleh Bagian Kredit dicatat dan disimpan kedalam Arsip FPP. Berdasarkan Arsip FPP tersebut Bagian Kredit membuat Bukti Peminjaman yang diberikan kepada Anggota yang berisi No. BP, tgl BP, Nomor Anggota, Nama Anggota, Jumlah Realisasi, Lama Angsuran, Jumlah Angsuran dan Bunga.
• Setiap Bulan Anggota diharuskan membayar Angsuran sejumlah Angsuran yang disepakati pada saat Peminjaman yang kemudian oleh bagian Kredit dicatat dan direkam kedalam Arsip Angsuran. Berdasarkan Arsip Angsuran tersebut bagian Kredit membuat Bukti Angsuran yang diberikan kepada Anggota yang berisi No. BA, Tanggal BA, No. BP, Jumlah Angsur dan Bunga • Pada akhir bulan Bagian Kredit selalu membuat Laporan Peminjaman dan Laporan Angsuran yang diberikan Kepada Ketua Koperasi.
Latihan Activity Diagram ! PT. Nusantara adalah sebuah perusahaan yang bergerak dibidang penjualan Tunai barang-barang elektronik. Semua transaksi di perusahaan masih dilakukan secara manual. Berikut ini adalah kegiatan kegiatan yang dilakukan oleh bagian Penjualan dalam melaksanakan transaksi penjualan Barang di dalam perusahaan. 1. Pemesanan barang Setiap kali Bagian penjualan akan menjual barang ia selalu menerima surat pesanan dari pelanggan. Berdasarkan Surat pesanan tersebut bagian penjualan kemudian mencatat dan merekamnya kedalam Arsip Surat Pesanan. Berdasarkan Arsip surat pesanan tersebut, bagian penjualan membuatkan Faktur dan Surat Jalan yang dikirimkan kepada Pelanggan sebagai bukti bahwa barang yang dipesan sudah terealisasi dan rangkapnya disimpan sebagai Arsip Faktur dan Arsip Surat Jalan.
2. Pembuatan Kwitansi Apabila Faktur dan Surat Jalan sudah sampai ditempat pelanggan, maka pelanggan megirimkan Pembayaran yang kemudian oleh bagian penjualan dibuatkan Kwitansi yang dibuat berdasarkan Arsip Faktur yang kemudian diserahkan kepada pelanggan sebagai bukti pembayaran dan rangkapnya disimpan kedalam Arsip Kwitansi 3. Pembuatan Laporan Setiap akhir bulan Bagian Penjualan selalu membuat Laporan Penjualan berdasarkan Arsip Faktur dan Laporan Pesanan berdasarkan Arsip Pesanan dan Laporan Pengiriman berdasarkan Arsip Surat Jalan yang ditujukan kepada Kepala Bagian Penjualan Diminta : • Buatlah Activity diagram dari data diatas !
Sequence Diagram • Sequence diagram menggambarkan interaksi antar objek di dalam dan di sekitar sistem (termasuk pengguna, display, dan sebagainya) berupa message yang digambarkan terhadap waktu. Sequence diagram terdiri atar dimensi vertikal (waktu) dan dimensi horizontal (objekobjek yang terkait).
• Sequence diagram biasa digunakan untuk menggambarkan skenario atau rangkaian langkahlangkah yang dilakukan sebagai respons dari sebuah event untuk menghasilkan output tertentu. Diawali dari apa yang men-trigger aktivitas tersebut, proses dan perubahan apa saja yang terjadi secara internal dan output apa yang dihasilkan. • Diagram ini secara khusus berasosiasi dengan use case diagram • Memperlihatkan tahap demi tahap apa yang seharusnya terjadi untuk menghasilkan sesuatu didalam use case
Simbol Sequence Diagram
Contoh Sequence Diagram
Contoh kasus Penggajian
(Acknowledgments Evi Lutfi Muktar)
SEQUENCE DIAGRAM INPUT DATA PEGAWAI
SEQUENCE DIAGRAM INPUT DATA PENDIDIKAN
SEQUENCE DIAGRAM INPUT DATA KELUARGA
SEQUENCE DIAGRAM ABSEN MASUK
Contoh kasus PLN (Acknowledgments Toeko triyanto)
: administrator
: formtambah manajemen user : control formtambah manajemen user
open ( ) get username, password nama lengkap, email
display username, password nama lengkap, email simpan
simpan
: pelanggan
: pelanggan open ( )
: formtambah pendaftaran
: controlform tambah pendaftaran
: pelanggan1
get nomor_pelanggan peruntukan, tarif, daya
display nomor_pelanggan nama pelanggan alamat nomor ktp nomor telpon gardu daya tarif lama daya tarif baru peruntukan simpan simpan
display no, agenda, tgl, id_pelanggan nama, daya_lama daya_baru, status, aksi
• Collaboration diagram juga menggambarkan interaksi antar objek seperti sequence diagram, tetapi lebih menekankan pada peran masing-masing objek dan bukan pada waktu Penyampaian message. • Setiap message memiliki sequence number, di mana message dari level tertinggi memiliki nomor 1. Messages dari level yang sama memiliki prefiks yang sama.
Contoh Collaboration Diagram
Berikut adalah sebuah contoh collaboration diagram yang mengilustrasikan sebuah sistem telepon genggam (handphone) :
Collaboration Diagram (Acknowledgments Toeko triyanto) : sim pan
: tam bah data : cari
: info
: pengunjung
: register
: index\home
: pendaftaran
: batal
: sim pan
: cetak
: sim pan : m em ber
: index\hom e : m anajemen kontrol
: tambah modul : batal
: batal : login
: m anajem en modul
: logout
: hapus
: batal : update
: login1 : edit : brow se
: batal
: profile : sim pan : update : tam bah user
: cetak
: cari
: m anajemen user : batal
: tam bah data
: pendaftaran
: hapus
: sim pan
: update : cari
: cari
: batal
: edit : cetak dokum en : batal : cetak
: login1
: tam bah kw itansi
: index\hom e
: batal
: cari : admin
: cetak
: login : perintah kerja1 : batal : cetak : cari
: sim pan
: guestbook1
: tam bah guestbook
: data pelanggan1
: m anajem en kontrol1 : mutasi1
: perem ajaan
: batal
: edit
: hapus
: informasi tagihan1
: cari
: batal : cari
: cari : sim pan
: batal
: cari
: cetak : cari
: cetak dokum en : tam bah kw itansi
: sim pan
: kw itansi1 : batal : cetak : index\hom e
: user
: cari : sim pan
: perintah kerja1 : tambah guestbook
: guestbook1
: inform asi tagihan1 : cetak
: m utasi1 : data pelanggan1
: cari
: batal
: cari
: edit
: hapus
: cari
: simpan
: sim pan
: kw itansi1
: batal
: batal
: peremajaan
PERTEMUAN 6 COMPONENT DIAGRAM
Component Diagram
Component diagram menggambarkan struktur dan hubungan antar komponen piranti lunak, termasuk ketergantungan (dependency) di antaranya. Komponen piranti lunak adalah modul berisi code, baik berisi source code maupun binary code, baik library maupun executable, baik yang muncul pada compile time, link time, maupun run time. Umumnya komponen terbentuk dari beberapa class dan/atau package, tapi dapat juga dari komponenkomponen yang lebih kecil. Komponen dapat juga berupa interface, yaitu kumpulan layanan yang disediakan sebuah komponen untuk komponen 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 ,kumpulan aplikasi system ,component yang jalan di client , data file , technical component didalam system , source file
, table data dalam sebuah database , User interface (screen, pages, report) dll
Component Diagram
Dependencies • dimodelkan dengan garis terputus dengan panah terbuka • gambarkan dependencies dari kiri ke kanan Contoh: Source Code bergantung pada MySQL • Dimungkinkan sebuah component dependencies pada interfaces component lainnya Contoh:
Inheritance • inheriting/child component diletakkan dibawah parent component, dengan arah panah menuju ke parent component • dimodelkan dengan garis dengan panah tertutup Contoh: Menu Utama
Penjualan
Pembelian
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 lollipop Pada 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
Bentuk grafik
Component Diagram
port • adalah bentuk object yang menjelaskan interaksi antara object dan lingkungannya • digambarkan sebagai kotak kecil di pinggiran component
Assembly connector • Penghubung antara 2/lebih component dimana sebuah/beberapa component provides interfaces dan component lain required interfaces • Digambarkan dengan gabungan bentuk interfaces contoh:
Deployment Diagram Deployment/physical diagram menggambarkan detail bagaimana komponen di-deploy dalam infrastruktur sistem, di mana komponen akan terletak (pada mesin, server atau piranti keras apa), bagaimana kemampuan jaringan pada lokasi tersebut, spesifikasi server, dan hal-hal lain yang bersifat fisikal Sebuah node adalah server, workstation, atau piranti keras lain yang digunakan untuk men-deploy komponen dalam lingkungan sebenarnya. Hubungan antar node (misalnya TCP/IP) dan requirement dapat juga didefinisikan dalam diagram ini Deployment diagram digunakan untuk melayani pemodelan hardware yang digunakan dalam implementasi sistem dan asosiasinya antara komponen-komponen tersebut. Elemen yang digunakan dalam deployment diagram adalah nodes (ditunjukkan sebagai sebuah cube), komponen (ditunjukkan sebagai sebuah kotak bujursangkar) dan juga asosiasi.
• Deployment diagram ini menunjukkan hardware yang digunakan pada jaringan kantor yang kecil. Application server (node) terhubung dengan database server (node) dan database client (component) sudah terinstall 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/Microsoft Office, dll), akan tetapi software component tersebut akan digambarkan ketika 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 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: //code style sheet //javascript
Node - Deployment Diagram • Adalah hardware seperti – computer/PDA ,lap top, handphone – peralatan komunikasi data (router,hub,switch,modem) – dll Nama Node • Digambarkan dengan bentuk kotak 3 dimensi • Node dapat digabungkan dengan • Node dapat digambarkan component pada dengan bentuk visual, component diagram 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.
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
Client
*
1 Server
association dimungkinkan mempunyai multiplicity (0..1, 1..*, dll)
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 untuk menggambarkan software yang terdapat pada sebuah hardware • dimungkinkan sebuah node memiliki node yang lain faktur.asp dependencies 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
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 • Interaction Overview Diagram menggunakan notasi yang dipakai pada Activity diagram dan Sequence Diagram • Interaction, sd dilambangkan dengan gambar dibawah ini
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 waktu
keterangan gambar : object states Lifeline
Timing Constrant
:seminar proposed, scheduled, enrolling students, Being Taught, Final Exams, Closed | {Nov 1 .. Des 31} | {jan 1 .. July 31}
Timing Diagram – Robust notation
State /condition
Object Lifeline
Messag e
Composite Structure Diagram • •
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
atau
Composite Structure Diagram • 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, 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 Broker dengan berisi nama Role
• Package Diagram Sebuah bentuk pengelompokkan yang memungkinkan untuk mengambil sebuah bentuk di UML dan mengelompokkan elemen-elemennya dalam tingkatan unit yang lebih tinggi. Kegunaan package yang paling umum adalah untuk mengelompokkan class. •Package Diagram Menggambarkan pengelompokan dari suatu class-class
Entity Relationship Diagram (ERD) ERD adalah : Model untuk menjelaskan hubungan antar data dalam basis data berdasarkan suatu persepsi bahwa real word terdiri dari objek-object dasar yang mempunyai hubungan atau relasi antara objek-objek tersebut
TAHAP MEMBUAT ERD 1. Keluarkan semua atribut yang dimiliki oleh dokumen sumber 2. Tentukan Atribut yang dapat menjadi Primary Key jika TIDAK ADA boleh DIBUAT BARU lalu tentukan ketergantungan 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 masingmasing Entitas yang telah terhubung.
Notasi dan Penamaan Untuk Konstruksi Skema Diagram ER No 1.
2.
Simbol
Keterangan Entity Type Suatu yang ada (secara eksplisit keberadaannya dapat nyata dapat perbedaan antar entity harus jelas. Ex. Pegawai, Departemen
ada) namun virtual, serta
Weak entity Type Suatu entity yang tidak punya key atribut keberadaannya tidak perlu berdiri sendiri / diluar system. Didalam weak dimungkinkan 1 weak memiliki banyak entity. Setidaknyatidaknya memiliki 1 relasi. Ex. Karyawan
Departemen
Salary
3.
Attribute Keterangan yang dimilikientity / sifat-sifat yang melekat pada entity yang perlu dicatat. Ex. Pegawai: Nopeg, Nama, Alamat, Jenis Kel, tgl. Masuk
4.
Key Attribute Bila didalam attribute terdapat nilai sama, maka kita perlu membuat “Key attribute” sehingga dipastikan tidak akan terjadi nilai/record sama. Ex. Pegawai : sebagai key adalah NoPeg NoPeg Nama Alamat P01 Bella Malang P02 Bella Batu
5.
Multivalued Attribute Satu entity yang memiliki 2 attribute sama Ex. Departemen yang memiliki 2 lokasi pabrik Departemen Departemen
Lokasi
Hal ini bukan berarti bias untuk orang yang mempunyai 2 nama atau 2 alamat 6.
Composite Attribute Attribute yang mempunyai nilai attribute lebih dari Satu Ex. Nama : Nama Depan Alamat : Jalan Nama Tengah Nomer Nama Belakang Kota
7.
Derived Attribute Merupakan kombinasi dari attribute-attribute dimana keberadaannya tidak perlu disimpan. Ex. Mata Kuliah MHS
E1
E2
8.
Identifying Relationship Type Bila entity mempunyai hubungan lebih dari satu entity lain. E1
E2
9.
Relationship Type Menyatakan hubungan antar attribute sehingga terjadi pemetaan. Ex. M Mahasiswa
Bisa Ambi l
* * Range Domain
Hasil Dari Relasi : One To One (1:1) One To Many (1:N) Many To Many (1:M)
N Mat. Kul # # # # Kodomain
Derajat Relationship UNARY RELATIONSHIP
BINARY RELATIONSHIP
N-ARY RELATIONSHIP
ENTITY-RELATIONSHIP DIAGRAM
PEGAWAI
PUNYA
JABATAN
PEGAWAI
MEMPUNYAI
JABATAN
PEGAWAI
DIPUNYAI OLEH
JABATAN
PROYEK
KERJA
PEGAWAI
PROYEK
DIKERJAKAN OLEH
PEGAWAI
PROYEK
MENGERJAKAN
PEGAWAI
ENTITY-RELATIONSHIP DIAGRAM
PEGAWAI
1
PUNYA
1
JABATAN
1
1
1
1
PROYEK
1
KERJA
M
PEGAWAI
1
M
1
1
MHSISWA
M
IKUT
N
MT-KULIAH
1
M
M
1
ENTITY-RELATIONSHIP DIAGRAM
PEGAWAI
1
NO-PEG NAMA ALAMAT
PROYEK
NIM NAMA ALAMAT
1
NO-PEG KD-JAB
1
KD-PROY NM-PROY ANGGARAN
MHSISWA
PUNYA
KERJA
KD-JAB URAIAN TUNJANGAN
M
IKUT NIM KD-MATKUL NILAI
PEGAWAI NO-PEG NAMA HONOR
KD-PROY NO-PEG
M
JABATAN
N
MT-KULIAH KD-MATKUL NM-MATKUL SKS
ENTITY-RELATIONSHIP DIAGRAM
JENIS ENTITY PEGAWAI
1
ISI
M
ABSEN
STRONG ENTITY
WEAK ENTITY
TIDAK MEMPUNYAI KEY
PEGAWAI NO-PEG NAMA ALAMAT
1
ISI NO-PEG
M
ABSEN TANGGAL JAM-MASUK JAM-PULANG
ENTITY-RELATIONSHIP DIAGRAM
NO-PEG NO-PROY NO-PEG NAMA PEGAWAI GAPOK LAMA-KERJA JABATAN M
NO-PEG KD-BAG
PUNYA
1
KD-BAG NAMA-BAG
BAGIAN
1 M
KERJA
PROYEK
NO-PROY NAMA-PROY BIAYA
M
PAKAI
N BARANG
NO-PROY KD-BAR JUMLAH
KD-BAR HARGA-BAR NAMA-BAR
KASUS : ANALISA SISTEM BERJALAN Posedur Sistem Berjalan Perusahaan Bina Sarana Indonesia adalah perusahaan usaha dagang yang bergerak di bidang distributor penjualan elektronik (TV, kulkas, kipas angin, radio dan lain lain), Perusahaan ini menjual barang elektronik kepada customer secara tunai dengan nilai transaksi ≥ Rp. 50.000.000,-(lima puluh juta rupiah). Customer adalah badan usaha atau toko pengecer yang menjual produknya kepada pelanggan secara perorangan. Pada prosedur sistem berjalan ini, Customer pada saat memesan barang diharuskan melampiri dokumen PO terlebih dahulu, dan PO paling lama satu minggu untuk di konfirmasi pada Customer. Maka untuk lebih jelasnya prosedur dari sistem berjalan adalah sebagai berikut:
a. Prosedur Order Penjualan Setiap costumer dapat memesan barang datang langsung atau melalui faximile dengan menyertakan dokumen PO yang diterima oleh bagian penjualan. Kemudian bagian penjualan berdasarkan PO, memeriksa pesanan barang dengan menggunakan kartu stock, apabila stock barang ada maka di hitung nilai penjualan dan dicatat kedalam faktur penjualan. Jika stock barang tidak ada, maka di catat ke dokumen Daftar Permintaan Stock Barang (DPSB), faktur penjualan rangkap 4 (empat), yang telah di buat didistribusikan ke Kasir
b. Prosedur Pembayaran Tunai Setelah customer mendapat konfirmasi tentang pesanan pembelian disetujui, maka customer melakukan transaksi pembayaran melalui transfer uang ke bank yang ditunjuk dengan bukti setoran. Berdasarkan bukti setoran, Kasir membuka arsip penjualan yang dicocokan dengan bukti setoran. Apabila sesuai dengan nilai penjualan maka dibuatkan kwitansi lunas, dan merekap nilai penjualan Harian/Daily Sales Report (DSR). Distribusi dokumendokumen berdasarkan nilai transaksi penjualan sebagai berikut : untuk Kwitansi dan faktur penjualan di berikan kepada customer. Gudang mendapat tembusan pengeluaran barang dari kasir sesuai barang yang di pesan, dan Copy faktur diberikan ke Bagian Penjualan.
c. Prosedur Pennyiapan Barang kirim Gudang Setelah menerima Tembusan pengeluaran barang, maka menyiapkan barang yang akan dikirim dengan mencatat barang keluar ke kartu gudang dan membuat dokumen surat keluar barang yang ditembuskan ke bagian Penjualan. d. Prosedur Pengiriman Barang Bagian Penjualan berdasarkan Surat keluar barang, selanjutnya membuka arsip faktur penjualan untuk mencatat barang yang akan dikirim ke dokumen Surat Jalan. Dokumen surat keluar barang didistribusikan ke Bagian Pengiriman beserta barang dan disampaikan ke Customer
e.Prosedur Pembuatan Laporan Setiap akhir periode di buat laporan penjualan bulanan, berdasarkan rekap penjualan harian dan faktur penjualan. Laporan stock barang keluar berdasarkan Kartu Stock dan Kartu Gudang. Ke-dua laporan tersebut diberikan kepada Manajer Penjualan untuk 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 Sistem Penjualan
RANCANGAN SISTEM USULAN A. Prosedur Order Penjualan Setiap Customer dapat memesan barang datang langsung atau melalui faximile dengan menyertakan dokumen PO yang diterima oleh Bagian Penjualan. Kemudian Bagian Penjualan berdasarkan PO, mengecek jumlah pesanan dan status Customer dengan stock barang yang berada di file barang dan status Customer berdasarkan file Customer. Apabila stock barang ada maka di lakukan proses pengentrian transaksi nilai penjualan yang disimpan ke file faktur dan file Isi_faktur. Kemudian berdasarkan file faktur dan file Isi_faktur dicetak ke dokumen faktur penjualan(4 rangkap) yang dikirimkan ke Kasir.
B. Prosedur Pembayaran Tunai Setelah Customer mendapat konfirmasi tentang pesanan pembelian disetujui, maka Customer melakukan transaksi pembayaran melalui transfer uang ke bank yang ditunjuk dengan bukti setoran. Berdasarkan bukti setoran, Kasir membuka transaksi pembayaran dengan membuka database penjualan (file barang, file customer, file faktur, file Isi_faktur ). Kemudian data pembayaran disimpan kedalam file bayar. Berdasarkan file bayar maka dilakukan pencetakan kwitansi ( dua rangkap ). Semua dokumen penjualan 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 Penjualan Bagian Akunting melakukan proses up-date transaksi jurnal penjualan berdasarkan file bayar dan file perkiraan yang disimpan ke file jurnal. D. Prosedur Pengiriman Barang Bagian Penjualan membuat dokumen Surat Jalan (SJ) dengan mengentry jumlah barang yang dijual berdasarkan database penjualan(fie barang,file customer, file faktur dan file Isi_faktur) yang disimpan dalam file SJ dan file Isi_SJ. Dokumen SJ di berikan ke bagian Pengiriman yang diantar ke Customer. Dokumen SJ didistribusikan ke Gudang untuk menyiapkan barang agar dikirimkan Ke Customer.
E. Prosedur Pembuatan Laporan Setiap akhir periode di buat laporan penjualan bulanan, berdasarkan rekap penjualan harian dan faktur penjualan. Laporan stock barang keluar berdasarkan Kartu Stock dan Kartu Gudang. Ke-dua laporan tersebut diberikan kepada Manajer Penjualan untuk proses 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 dari keduanya dalam susunan berbentuk komponen sistem yang saling berhubungan sesuai dengan aturan mainnya a. DFD d. entity b. proses e. jaringan c. entitas 2. Simbol relationship pada ERD biasanya menggunakan keterangan berupa a. kata benda d. kata sifat b. kata kerja e. kata perintah c. kata pengganti
2. Simbol relationship pada ERD biasanya menggunakan keterangan berupa a. kata benda d. kata sifat b. kata kerja e. kata perintah c. kata pengganti 3. Dibawah ini adalah pernyataan yang benar dari aturan main DFD , kecuali… a. Dlm DFD tidak boleh menghubungkan antara EXTERNAL ENTITY dgn EXTERNAL ENTITY secara langsung b. Dlm DFD tidak boleh menghubungkan antara DATA STORE dgn DATA STORE secara langsung c. Dlm DFD tidak boleh menghubungkan antara DATA STORE 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
3. Dibawah ini adalah pernyataan yang benar dari aturan main DFD , kecuali… a. Dlm DFD tidak boleh menghubungkan antara EXTERNAL ENTITY dgn EXTERNAL ENTITY secara langsung b. Dlm DFD tidak boleh menghubungkan antara DATA STORE dgn DATA STORE secara langsung c. Dlm DFD tidak boleh menghubungkan antara DATA STORE 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 Nol b. Diagram Detail e. diagram Top Down c. Diagram Objek
4. Tahapan proses pembuatan DFD yang menggambarkan sistem secara global a. Diagram konteks d. Diagram Nol b. Diagram Detail e. diagram Top Down c. Diagram Objek
5. Gambar diatas adalah a. unary relationship b. N-ary relationship c. M-ary relationship
d. binary relationship e. ternary relationship
5. Gambar diatas adalah a. unary relationship b. N-ary relationship c. M-ary relationship
d. binary relationship e. ternary relationship
1. Suatu network yang menggambarkan suatu sistem automatic/ komputerisasi , manual dan gabungan dari keduanya dalam susunan berbentuk komponen sistem yang saling berhubungan sesuai dengan aturan mainnya a. DFD d. entity b. proses e. jaringan c. entitas
Pertemuan 9 PRINSIP DAN KONSEP DESAIN
Pokok Bahasan dalam RPL : Desain PL dan Rekayasa PL Prinsip Desain Konsep Desain Desain Modular Afektif Model Desain Dokumentasi Desain
Buku Referensi : • Pressman, RS., 2008, Software 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. • 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 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. – 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 classclass 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 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. 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 penemuanpenemuan 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 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 terbukti • 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 fungsi atau informasi secara konseptual. • Penyaringan membantu desainer untuk mengungkapkan detail tingkat rendah ketika desain berjalan.
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: 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 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. • 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 decision--makers decision
workers
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 3
function 1
function 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 terkendali • 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 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 • 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. • 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. - Hierarki class dapat di restrukturisasi sehingga atributatribut 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); 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 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 : 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: 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 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 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 – Strategi integrasi – Pertimbangan khusus
• Catatan Khusus • Lampiran
Pertemuan 10 METODE DESAIN (1)
Pokok Bahasan dalam RPL : Desain Data Desain Arsitektur Proses Desain Arsitektur Pasca Pemrosesan Desain Optimasi Desain Arsitektur
Buku Referensi : • Pressman, RS., 2008, Software Engineering: A Practitioner’s Approach, New York: McGraw-Hill • Sommerville, I, 2007, Software Engineering, Addsion Wesley
Tujuan Metode Desain • Menjelaskan maksud dari arsitektur PL dan kenapa sangat penting. • Memhami model data, struktur data, database, data warehouse, desain data pada level komponen
DESAIN DATA • • 1. 2. 3. 4. 5. 6. 7.
Aktivitas pertama (dan beberapa sering mengatakan yang terpenting) dari 4 aktivitas desain yang dilakukan selama RPL. Prinsip-prinsip : Prinsip analisis sistematik yang diaplikasikan pada fungsi dan perilaku seharusnya diaplikasikan juga pada data. Semua struktur data dan operasi yang dilakukan pada masing-masing struktur data harus diidentifikasi. Kamus data harus dibangun dan digunakan untuk menentukan baik data maupun desain program. Keputusan desain data tingkat rendah harus ditunda sampai akhir proses desain. Representasi stuktur data hanya boleh diketahui oleh modul-modul yang harus menggunakan secara langsung data yang diisikan didalam struktur terseb ut. Pustaka struktur data dan operasi yang berguna yang dapat diaplikasikan pada struktur data tersebut harus dikembangan. 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. • 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. 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. • 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. 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)
a
b d
e
h
g
f
i
c
j
data flow model x1 x2 b
x4
x3 c
a
"Transform" mapping
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 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)
Program Architecture
PASCA PEMROSESAN DESAIN Tugas yang harus dilakukan : • Mengembangkan narasi pemrosesn untuk masingmasing modul. • Menyediakan deskripsi interface untuk masingmasing modul. • Menentukan struktur data lokal dan global. • Mencatat semua batasan desain. • Mengkaji desain. • Mempertimbangkan “optimasi” (bila diperlukan dan dibenarkan).
OPTIMASI DESAIN ARSITEKTUR Pendekatan : 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 (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)
Pokok Bahasan dalam RPL : Desain Interface Desain Interface Manusia – Mesin Desain Prosedural Coding
Buku Referensi : • Pressman, RS., 2008, Software Engineering: A Practitioner’s Approach, New York: McGraw-Hill • Sommerville, I, 2007, Software Engineering, Addsion Wesley
Tujuan Metode Desain • Menjelaskan maksud dari arsitektur PL dan kenapa sangat penting. • Memhami model data, struktur data, 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 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 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.
DESAIN INTERFACE MANUSIA MESIN (lanjutan) 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 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.
DESAIN INTERFACE MANUSIA MESIN (lanjutan) 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. 5. Bagaimana informasi help distruktur.
DESAIN INTERFACE MANUSIA MESIN (lanjutan) Peranti Implementasi User Interface Development : - Mengatur perangkat input (mouse / keyboard) - Menvalidasi input pemakai. - 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.
DESAIN INTERFACE MANUSIA MESIN (lanjutan) 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 ratarata argumen per perintah atau operasi individual per aksi, 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.
PEDOMAN DESAIN INTERFACE 1. Interaksi Umum - Konsisten - berikan umpan balik - Verifikasi terhadap aksi destruktif yang signifikan. - kemudahan pembatalan sebagian besar aksi. - kurangi jumlah informasi yang harus diingat diantara aksiaksi. - 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. 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 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 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) 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 gagasan terstruktur, deklarasi data dan karakteristik modularitas. 2. Sintaks bebas dari bahasa natural yang menggambarkan ciriciri 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 akhir produksi PL Tahap ini merupakan proses pembuatan kode program dalam bahasa pemrograman tertentu sesuai dengan platform dan kesepakatan dengan customer. Merupakan tahap transformasi dari hasil desain ke dalam program yang dpt dijalankan pada komputer yang akan digunakan di dalam sistem. Baik buruknya implementasi sangat tergantung pada baik buruknya hasil final dari tahap desain
Makna & Tujuan Implementasi (2) Melibatkan pengintegrasian semua komponen rancangan sistem termasuk PL, konversi ke sistem operasi. Proses implementasi melibatkan: Perencanaan Pengeksekusian
Rencana Implementasi (1) Rencana ini merupakan formulasi rinci dan representasi grafik mengenai cara pencapaian implementasian sistem yang akan dilaksanakan (tergantung pada kompleksitas proyek) 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 yang akan digunakan Micro, mini atau mainframe) Listrik, telepon, koneksi lainnya, ventilasi, AC, keset anti debu, karpet, rak, penyangga barang, meja, penyimpan disk/pita, lemari kabinet, tempat personil, lokasi printer, dudukan printer, dan furniture lain yg dirancang secara ergonomis Pengujian burn in (simulasi operasi pd vendor)
Hal Penting Dalam Implementasi (2) 2. Pelatihan Personil Tdk ada sistem yang bekerja secara memuaskan jika para pemakai dan orang lain yang berinteraksi dengan sistem tersebut tidak dilatih secara benar Pelatihan personil tidak hanya meningkatkan keahlian/ketrampilan pemakai, namun juga memudahkan penerimaan mereka terhadap sistem baru Pelatihan meningkatkan kepercayaan diri, meminimalkan sesi kesalahan, kerusakan pada tahap awal.
Hal Penting Dalam Implementasi (3) Sasaran pelatihan: 1. Personil teknis yang akan mengoperasikan dan memelihara sistem tersebut. 2. Berbagai pekerja dan supervisor yang akan berinteraksi langsung dengan sistem untuk mengerjakan tugas dan 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
Hal Penting Dalam Implementasi (4) 4. Program Pelatihan: Pelatihan in house Pelatihan yang disediakan oleh vendor Jasa pelatihan luar 5. Teknik dan Alat Bantu Pelatihan: Teleconferesi PL pelatihan interaktif Pelatihan dengan instruktur Pelatihan magang Manual prosedur Buku teks
Hal Penting Dalam Implementasi (5) 6. Software Untuk Pelatihan Interaktif: CBT (Computer-Based Training) ABT (Audio-Based Training) VBT (Video-Based Training) 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 oleh pemakai.
Hal Penting Dalam Implementasi (6) Tujuan dokumentasi: 1. Pelatihan 2. Penginstruksian 3. Pengkomunikasian 4. Penetapan standar kinerja 5. Pemeliharaan sistem 6. Referensi historis Empat area utama dokumentasi: 1. Dokumen pemakai 2. Dokumen Sistem 3. Dokumen Perangkat lunak 4. Dokumen operasi
Hal Penting Dalam Implementasi (7) Penjelasan Tanpa dokumentasi yang jelas dan akurat Pengembangan sistem
Hal Penting Dalam Implementasi (8) 8. Konversi File & Sistem Merupakan proses pengubahan dari sistem lama ke sistem baru Kompleksitas dalam pengkonversian tergantung pada beberapa faktor, yaitu : Jenis Perangkat Lunak Database HardWare Kendali Jaringan Prosedur
Hal Penting Dalam Implementasi (9) Metode konversi: 1. Konversi Langsung Sistem yang lama langsung digantikan dengan sistem yang baru 2. Konversi Paralel Sistem lama masih dijalankan sambil menjalankan sistem baru, jika sistem baru sudah dianggap stabil maka sistem lama akan dihentikan 3. Konversi Phase-in Sistem lama digantikan secara berangsur angsur sedikit demi sedikit akhirnya sistem lama akan tergantikan dengan sistem baru 4. Konversi Pilot Dilakukan 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 kegagalan sistem baru Biaya yang dibutuhkan cukup besar karena keduanya harus jalan bersama-sama
Sistem baru di implementasikan sedikit demi sedikit untuk 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 pada seberapa jauh profesional sistem menyiapkan konversi file data yang diperlukan di dalam sistem baru Konversi/Modifikasi Meliputi: 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 dan phase-in Selama konversi file perlu diperhatikan prosedur kendali untuk memastikan integrasi data Prosedur kendali utk masing2 file berbeda Suatu transaksi diterima dan dimasukkan ke dalam sistem Program mencari file master baru untuk record yang akan diupdate oleh transaksi tsb.jika record tsb ada maka pengupdatean record selesai
Konversi File Data (3) 2. Konversi File Gradual (Lanjutan) Jika record tidak ditemukan dalam file master baru, file master lama diakses untuk record yang tepat, dan ditambahkan pada file master baru dan diupdate Jika transaksi untuk record baru, record baru disiapkan 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 untuk ditata ulang dalam sebuah implementasi Level abstraksi pada desain, misal class, modul, algoritma, struktur data, dan tipe data harus diwujudkan dalam implementasi Antarmuka antara komponen sistem perangkat lunak harus diwujudkan secara jelas pada tahap implementasi Kode program tersebut harus dapat di cek konsistensinya pada setiap objek dan operasinya secara langsung menggunakan kompilator.
Kriteria Lingkungan Pemrograman 1. Modularity (Modularitas) Program dapat dibuat dalam bentuk modul2 yang lebih kecil dan mudah dalam integrasinya 2. Dokumentasi Nilai Pada Bahasa Pemrograman Dokumentasi mengenai penjelasan coding/komponen yang digunakan 3. Struktur Data Dalam Bahasa Pemrograman Ketersediaan struktur data yang kompleks akan membantu mempermudah proses 4. Struktur Aliran Pengendali Suatu kasus khusus melibatkan suatu pengujian kondisi dan akan memberikan alternatif untuk dilaksanakan sesuai 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. Integritas Kemudahan dalam pembacaan dan mekanisme dalam pengecekan tipe dan antarmodul 7. Portability (Multiplatform) Bahasa pemrograman atau hasil programnya dapat dijalankan di beberapa platform yang berbeda 8. Dukungan Dialog Fasilitas interaktif dari program dengan lingkungan luar
Kriteria Lingkungan Pemrograman (3) 9. Quality Kualitas kompilator sangat tergantung pada fitur-fitur yang disediakan dan mampu mendukung kinerja pembuataan koding yang bekualitas. 10. Ketersediaan Pustaka (Library) Menyediakan pustaka/library aplikasi yang kompleks
yang
bervariasi
11. Ketersediaan Tool Pembangunan Semua peralatan terintegrasi dalam satu interface
untuk
Kriteria Lingkungan Pemrograman (4) 12. Kebijakan Instansi (Tim) Pemilihan bahasa pemrograman ditentukan institusi (tim) atau oleh penggunanya
oleh
13. Kebutuhan Eksternal Adanya tambahan alat baru atau PL baru yang harus terhubung dengannya
Programming Style Menulis sebuah program adalah seni dan merupakan proses yang kreatif Gaya pemrograman pada programmer mempengaruhi tingkat kemudahan pembacaan program yang dibuatnya Buku Code Complete Mengulas tuntas suatu gaya pemrograman bahkan di dalamnya diberkan contoh variasi yang cukup banyak. Gaya pemrograman yang baik sangat didukung dari tahap desain dan perencanaan implementasi yang baik
PERTEMUAN 13 STRATEGI PENGUJIAN PERANGKAT LUNAK
Strategi uji coba perangkat lunak dilakukan untuk memudahkan para perancang untuk menentukan keberhasilan system yang telah dikerjakan
Proses Testing Unit Testing
Module Testing
Component Testing
Sub-system Testing
Integration Testing
System Testing
Acceptance Testing
User Testing
3
Proses Testing Unit testing Pengujian masing-masing unit komponen program untuk meyakinkan bahwa sudah beroperasi secara benar Module Testing Pengujian terhadap koleksi unit-unit komponen yang saling berhubungan. Sub-system Testing Pengujian terhadap koleksi module-module membentuk suatu sub-system (aplikasi)
yang
4
Proses Testing System Testing Pengujian terhadap integrasi sub-system, keterhubungan antar sub-system
yaitu
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 pengujian dilakukan oleh potensial customer) 5
Rencana Pengujian Proses testing Deskripsi fase-fase utama dalam pengujian Pelacakan Kebutuhan Semua kebutuhan user diuji secara individu Item yg diuji Menspesifikasi 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 tersebut dijalankan
Prioritas Testing Hanya test yang lengkap yang dapat meyakinkan sistem terbebas dari kesalahan, tetapi hal ini sangat sulit dilakukan. Prioritas dilakukan terhadap pengujian kemampuan sistem, bukan masing-masing komponennya. Pengujian untuk situasi yang tipikal lebih penting dibandingkan pengujian terhadap nilai batas.
Test Data Dan Kasus Test Test Data Input yang direncanakan digunakan oleh sistem. Test Cases Input yang digunakan untuk menguji sistem dan memprediksi output dari input jika sistem beroperasi sesuai dengan spesifikasi.
Pendekatan Strategis Pengujian Perangkat Lunak
Pengujian Unit Pengujian Integrasi Pengujian Validasi Pengujian Sistem
Pengujian Unit Berfokus pada inti terkecil dari desain perangkat lunak yaitu modul Uji coba unit selalu berorientasi pada white box testing Dapat dikerjakan paralel atau beruntun dengan modul lainnya.
Pengujian Unit (2)
Pengujian Unit (3)
Apakah jumlah parameter input sama dengan jumlah argumen? Apakah antara atribut dan parameter argumen sudah cocok? Apakah antara sistem satuan parameter dan argumen 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 satuan parameter?
Pengujian Unit (4) Apakah jumlah atribut dan urutan argumen ke fungsifungsi built-in sudah benar? Adakah referensi ke parameter yang tidak sesuai dengan poin entri yang ada? Apakah argumen input only diubah? Apakah definisi variabel global konsisten dengan modul ? Apakah batasan yang dilalui merupakan argumen?
Pengujian Unit (5) Test case harus didesain untuk mengungkap kesalahan dalam kategori 1. Pengetikan yang tidak teratur dan tidak konsisten inisialisasi yang salah atau nilai-nilai default 2. Nama variabel yang tidak benar 3. Tipe data yang tidak konsisten 4. Underflow, overflow dan pengecualian pengalamatan
Seberapa Baik Sistem Yang Sudah di Bangun Dua Aspek yang dipertimbangkan: Apakah implementasi sudah sesuai dengan spesifikasi ? Apakah spesifikasi sesuai dengan kebutuhan user ? Validasi Apakah sistem yang dikembangkan sudah benar? Pengujian dimana sistem ketika diimplementasikan sesuai dengan yang diharapkan Verifikasi Apakah sistem dikembangkan dengan cara yang benar ? Pengujian apakah sistem sudah sesuai dengan spesifikasi
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 mengurangi masalah tersebut.
A
T1
T1
A T1
T2
A
T2 T2
B
B
T3 T3
B
C T4
T3 C
T4 T5
D Test sequence 1
Test sequence 2
Test sequence 3
Pendekatan Integration Testing Top-down Testing Berawal 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 Testing Integrasi components di level hingga sistem lengkap sudah teruji. Pada prakteknya, kebanyakan test integrasi menggunakan kombinasi kedua strategi pengujian tsb.
Top Down Testing Level 1
Testing sequence
Level 2 Level 2 stubs
Level 3 stubs
Level 1
Level 2
Level 2
...
Level 2
Bottom Up Testing Test drivers Level N
Test drivers
Level N
Level N–1
Level N
Level N–1
Level N
Level N
Level N–1
Testing sequence
Pendekatan Testing Architectural Validation Top-down integration testing lebih baik digunakan dalam menemukan error dalam sistem arsitektur. System Demonstration Top-down integration testing hanya membatasi pengujian pada awal tahap pengembangan system. Test Implementation Seringkali lebih mudah dengan menggunakan bottomup 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 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
Volume Testing Stress Testing Performance Testing Data Recovery 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: 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 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 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, 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 , 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 pada beberapa user yang tidak memiliki privilege access ke database. Shutdown database engine melalui operating system (dengan beberapa perintah OS) yang dapat mematikan aplikasi database.
Debugging
PERTEMUAN 14
TEKNIK PENGUJIAN PERANGKAT LUNAK
TESTING Pengujian perangkat lunak adalah proses menjalankan dan mengevaluasi sebuah perangkat lunak secara manual maupun otomatis untuk menguji apakah perangkat lunak sudah memenuhi persyaratan atau belum, atau untuk menentukan perbedaan antara hasil yang diharapkan dengan hasil sebenarnya. Pengujian merupakan suatu tahapan pengerjaan yang bertujuan mencari kesalahan program. Kesalahan yang terjadi selama proses pengembangan perangkat lunak akan mengakibatkan bertambahnya waktu untuk menyelesaikan pekerjaan tersebut. Pengujian hendaknya dilakukan pada setiap tahap pengembangan yaitu mulai dari tahap analisis kebutuhan sampai dengan tahap perawatan.
KENAPA HARUS DIUJI ? Kita bukan seorang programmer yang cukup baik Kita mungkin tidak dapat cukup berkonsentrasi untuk menghindari kesalahan Kita terkadang lupa menggunakan pemrograman terstruktur secara penuh, perancangan atas-bawah untuk mendapatkan solusi Kita kadang buruk dalam mengerjakan sesuatu
KENAPA HARUS DI UJI (2) Kita seharusnya dapat membedakan apa yang dikatakan programmer lain atau pelanggan dan apa yang sebenarnya mereka pikirkan Kita seharusnya merasa bersalah apabila seseorang harus menguji koding kita Pengujian kesalahan
merupakan
suatu
perizinan
terhadap
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 sebelum pengujian itu dimulai. 3. Prinsip Pareto berlaku untuk pengujian PL. Prinsip Pareto mengimplikasikan 80% dari semua kesalahan yang ditemukan selama pengujian sepertinya akan dapat ditelusuri sampai 20% dari semua modul program.
PRINSIP PENGUJIAN (2) 4. Pengujian harus mulai "dari yg kecil" dan berkembang ke pengujian "yang besar". 5. Pengujian yg mendalam tidak mungkin. 6. Paling efektif, pengujian dilakukan oleh pihak ketiga yang independen
SASARAN PENGUJIAN
Glen Mayers menyatakan sejumlah aturan yang dapat dipandang sebagai sasaran dari pengujian Pengujian perangkat lunak adalah suatu proses pengeksekusian program dengan tujuan menemukan kesalahan (error) Pengujian (Test case) yang baik adalah yang mempunyai probabilitas yang tinggi untuk menemukan error yang tak diketemukan Pengujian yang sukses adalah pengujian yang dapat menemukan kesalahan (error) yang tidak ditemukan sebelumnya
7
TUJUAN PENGUJIAN Tujuan yang diinginkan dari pelaksanaan pengujian perangkat lunak adalah : Menilai apakah perangkat lunak yang dikembangkan telah memenuhi kebutuhan pemakai. Menilai apakah tahap pengembangan perangkat lunak telah sesuai dengan metodologi yang digunakan. Membuat dokumentasi hasil pengujian yang menginformasikan kesesuaian perangkat lunak yang diuji dengan spesifikasi yang telah ditentukan.
TEST ABILITAS Testabilitas Perangkat Lunak adalah seberapa mudah sebuah program komputer dapat diuji. Karena pengujian sangat sulit, perlu diketahui apa yang dapat dilakukan untuk membuatnya menjadi mudah.
Karakteristik PL yang Di Uji OPERABILITAS Semakin baik dia bekerja semakin efisien dia dapat diuji. OBSERVABILITAS Apa yang anda lihat adalah apa yang anda uji. KONTROLABILITAS Semakin baik kita dapat mengontrol PL, semakin banyak pengujian yang dapat diotomatisasi dan dioptimalkan. DEKOMPOSABILITAS Dengan mengontrol ruang lingkup pengujian kita dapat lebih cepat mengisolasi masalah dan melakukan pengujian kembali.
Karakteristik PL yang Di Uji (2) KESEDERHANAAN Semakin sedikit yg diuji semakin cepat pengujian. STABILITAS Semakin sedikit perubahan semakin sedikit gangguan pengujian. KEMAMPUAN DIPAHAMI Semakin banyak informasi yang dimiliki semakin detail pengujiannya.
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 produk yang telah dirancang untuk diperlihatkan, test dapat dilakukan untuk menilai masing-masing fungsi apakah telah berjalan sebagaimana yang diharapkan. 2. Pengetahuan tentang cara kerja dari produk, test dapat dilakukan untuk memperlihatkan cara kerja dari produk secara rinci sesuai dengan spesifikasinya.
PERANCANGAN TEST CASE Dua macam pendekatan test yaitu : 1. Black Box Testing Test case ini bertujuan untuk menunjukkan fungsi Perangkat Lunak tentang cara beroperasinya beroperasinya,, apakah pemasukan data keluaran telah berjalan sebagaimana yang diharapkan dan apakah informasi yang disimpan secara eksternal selalu dijaga kemutakhirannya kemutakhirannya..
PERANCANGAN TEST CASE (2) 2. White Box Testing (Structural Testing) Adalah meramalkan cara kerja perangkat lunak secara rinci rinci,, karenanya logikal path (jalur logika logika)) perangkat lunak akan ditest dengan menyediakan test case yang akan mengerjakan kumpulan kondisi dan atau pengulangan secara spesifik. spesifik. Secara sekilas dapat diambil Dijamin semua independent path (jalur bebas) bebas) telah dijalankan setidaknya satu kali
Teknik Pengujian Per.Lunak@Berta
16
PERANCANGAN TEST CASE (3) White Box (Lanjutan Lanjutan)) Menjalankan semua keputusan logis pada sisi true & false Menjalankan semua looping Melakukan struktur data internal untuk menjamin validitas kesimpulan white box testing merupakan petunjuk untuk mendapatkan program yang benar secara 100% 100%.
Teknik Pengujian Per.Lunak@Berta
17
WHITE BOX TESTING 1. Basis Path Testing Teknik uji coba White Box yang diusulkan Tom Mccabe (1976). Metode ini memungkinkan perancang test case mendapatkan ukuran kekompleksan logical dari perancangan prosedural dan menggunakan ukuran ini sebagai petunjuk untuk mendefinisikan basis set dari jalur pengerjaan. Test case yang didapat digunakan untuk mengerjakan basis set yang menjamin pengerjaan setiap perintah minimal satu kali selama uji coba. Contoh dari Basis Path Testing : Notasi Diagram Alir Cyclomatic Complexity Graph Metrix
WHITE BOX TESTING (2) 2. Loop Testing Loop Sederhana Pengujian loop sederhana dilakukan dgn mudah, dimana n jumlah maksimum yg diijinkan melewati loop tsb. 1. Lewati loop secara keseluruhan 2. Hanya satu yg dapat melewati loop 3. m dapat melewati loop dimana m< n Loop terangkai Loop tidak terstruktur 19
WHITE BOX TESTING (3) Loop Tersarang Pengujian loop ini menggunakan pendekatan loop sederhana.. Petunjuk pengujian loop tersarang : sederhana 1. Dimulai dari loop paling dalam dalam.. Atur semua loop ke nilai minimum minimum.. 2. Kerjakan dgn prinsip loop sederhana untuk loop yg paling dalam sementara tahan loop yg di luar pada parameter terkecil (nilai kounter terkecil terkecil)) 3. Kemudian lanjutkan untuk loop yg diatasnya diatasnya.. 4. Teruskan sampai semua loop selesai di uji. uji.
WHITE BOX TESTING (4) Loop Terangkai Pengujian loop ini menggunakan pendekatan loop sederhana bila masing-masing loop independen, tetapi bila dua loop dirangkai dan pencacah loop 1 digunakan sebagai harga awal loop 2 maka loop tsb jadi tidak independen, maka pendekatan yang diaplikasikan ke loop tersarang direkomendasikan. Loop Tidak Terstruktur Kapan saja memungkinkan, loop ini didisain kembali agar mencerminkan penggunaan komsepsi pemrograman tertruktur.
BASIS PATH TESTING (3) Perancangan Prosedural Dalam Bentuk Flowchart
BASIS PATH TESTING (4 (4) Gambar Grafik Alir
Lingkaran/node : Menggambarkan satu/lebih perintah prosedural. Urutan proses dan keputusan dapat dipetakan dalam satu node. Tanda panah/edge : Menggambarkan aliran kontrol. Setiap node harus mempunyai tujuan node Region : Adalah daerah yg dibatasi oleh edge dan node. Termasuk daerah diluar grafik alir.
Program Flow Graphs
Menggambarkan alur kontrol kontrol.. Setiap cabang ditunjukkan oleh path yang terpisah dan loop ditunjukkan oleh arrows looping kembali ke loop kondisi node node.. Digunakan sebagai basis untuk menghitung cyclomatic complexity Cyclomatic complexity = Jumlah edges – Jumlah Node +2 Cyclomatic complexity menyatakan jumlah test untuk menguji control statements
