Pertemuan 1 REKAYASA PERANGKAT LUNAK

Transkripsi

1 Pertemuan 1 PENGENALAN REKAYASA PERANGKAT LUNAK

2 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

3 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

4 Buku Referensi: Pressman, RS., 2008, Software Engineering: A Practitioner s Approach, New York: McGraw-Hill Sommerville, I, 2007, Software Engineering, Addsion Wesley

5 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

6 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

7 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

8 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

9 Produk Perangkat Lunak (3) Perbedaan PENTING antara 2 bentuk perangkat lunak : Pada produk generik, organisasi yang mengembangkan perangkat lunak mengontrol spesifikasi perangkat lunak. Pada produk pesanan, spesifikasi biasanya dikembangkan dan dikontrol oleh organisasi yang membeli perangkat lunak tersebut.

10 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

11 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

12 Jenis-jenis aplikasi Perangkat Lunak (2) Perangkat Lunak Teknik Dan Ilmu Pengetahuan (Scientific & Engineering Software) 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

13 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 Lunak Sistem Informasi (Information System) Perangkat lunak yg mampu memberi informasi dari suatu sistem secara lebih detail. Misal: web site, perpustakaan digital, dll

14 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 Lunak Komunikasi (Communicaion Software) Perangkat lunak yg berfungsi untuk menghubungkan atau mengkomunikasikan suatu objek satu dengan lainnya. Misal: router, handphone, dll

15 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

16 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

17 Evolusi Perangkat Lunak (2) Era I ( ): 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 an/awal 1960-an) Belum didefinisikan secara jelas tentang aspek software engineering

18 Evolusi Perangkat Lunak (3) Era II ( ) 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.

19 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

20 Evolusi Perangkat Lunak (5) Era III ( ) 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

21 Evolusi Perangkat Lunak (6) Era IV ( ) 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

22 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

23 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.

24 Mitos1: Mitos Dalam Perangkat Lunak (Management) 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

25 Mitos2: Mitos Dalam Perangkat Lunak (Management) (2) 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.

26 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.

27 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.

28 Mitos1: Mitos Dalam Perangkat Lunak (Praktisi) 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.

29 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.

30 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

31 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.

32 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

33 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.

34 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.

35 Pelaku Dalam RPL Manajer 1. Manajer proyek 2. Manajer konfigurasi 3. Manajer penjamin kulitas PL 4. Manajer bidang lainnya (sesuai kebutuhan Software Developer 1. Analis sitem 2. Desainer 3. Programmer 4. Inspektor PL 5. Pengontrol perubahan

36 Pelaku Dalam RPL (Lanjutan) Pendukung 1. Staf administrasi 2. Humas 3. Pencatat teknis 4. Administrator database 5. Administrator jaringan

37 Pertemuan 2 SOFTWARE DEVELOPMENT LIFE CYCLE (SDLC)

38 POKOK BAHASAN BiayaPL Software Quality Attribute Standar kualitas Takaran Jaminan Kualitas CASE TOOLS Siklus Hidup Perangkat Lunak (SWDLC/Software Development Life Cycle)

39 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

40 SOFTWARE QUALITY ATTRIBUTE (1) Ciri-ciri kualitas menurut lembaga penjamin mutu PL (ISO, ANSI, IEEE, dll): Correctness (kebenaran) Kesesuaian antara kode program dg spesifikasi Kebebasan aplikasi aktual pada sistem PL Reliability (tahan uji) Didasari pada correctness dan availability (ketersediaannya) Sebagai suatu kemungkinan bahwa sistem ini mampu memenuhi suatu kegunaan (tergantung spesifikasinya) untuk sejumlah masukan percobaan di bawah kondisi masukan dan rentang waktu yang telah ditentukan.

41 SOFTWARE QUALITY ATTRIBUTE (2) User Friendliness (mudah digunakan) Adequacy (kecukupan) Learnability (mudah dipelajari) Robustness (antisipasi kesalahan) Maintenatibility (mudah dirawat) Readability (mudah dibaca) Extensibility (mudah diperluas) Testability (mudah untuk diuji/ditelusuri) Efficiency (efisiensi) Portability (mudah didistribusikan)

42 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

43 UKURAN JAMINAN KUALITAS (2) Ukuran Organisasi (Organization Measures) Pengalaman pengembang (developer) dalam mempelajari strategi dan teknik yang tepat dalam membangun PL

44 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.

45 KODE ETIK PROFESI Konfidensialitas (menghormati klien) Tidak boleh menerima pekerjaan di luar kompetensinya Hak kekayaan intelektual (HaKI) Penyalahgunaan komputer, hack, crack,

46 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)

47 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)

48 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

49 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.

50 MODEL PROSES RPL Model Waterfall, Model Prototyping, Model Evolutionary Model Spiral Reuse Based Development

51 WATERFALL MODEL Requirement Definitions Pemodelan Sistem/ Informasi System and software design Implementation and unit testing Integr ation and system testing Operation and maintenance

52 WATERFALL MODEL (2) Requirements Analysis And Definition Pembentukan kebutuhan System And Software Design Mengubah kebutuhan-kebutuhan menjadi bentuk 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

53 WATERFALL MODEL (3) Problems Model Waterfall 1. Jarang sekali proyek yang prosesnya bisa dilakukan secara sequencial. 2. Sukar bagi customer untuk secara explisit mengemukakan semua kebutuhannya. 3. Customer harus sabar. 4. Developer sering menunda pekerjaan. Anggota tim harus menunggu anggota lainnya 5. menyelesaikan tugasnya.

54 PROTOTYPE MODEL Mendengarkan Pelanggan Membangun Konstruksi (prototipe) Uji Pelanggan (evaluasi)

55 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.

56 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.

57 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.

58 EVOLUTIONARY MODEL

59 Penjelasan : EVOLUTIONARY MODEL INCREMENTAL (2) 1. Kombinasikan elemet-element dari waterfall dengan sifat iterasi/perulangan. 2. Element-element dalam waterfall dikerjakan dengan hasil berupa produk 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.

60 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.

61 EVOLUTIONARY MODEL INCREMENTAL (4) Kekurangan Incremental Model: Hanya cocok untuk proyek berukuran kecil (tidak lebih dari baris coding) Mungkin terjadi kesulitan untuk memetakan kebutuhan pengguna ke dalam rencana spesifikasi masingmasing hasil increment

62 EVOLUTIONARY MODEL SPIRAL

63 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

64 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.

65 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

66 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.

67 REUSE BASED (3)

68 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.

69 Pertemuan 3 Manajemen Proyek Perangkat Lunak

70 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

71 Langkah Awal dalam Manajemen Perangkat Lunak Untuk mengestimasi biaya, pembagian tugas, dan penjadwalan, sebelum sebuah proyek direncanakan : Memastikan tujuan dan ruang lingkup Memperhatikan alternatif-alternatif solusi Identifikasi batasan teknik dan manajerial

72 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

73 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)

74 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

75 Fokus Dalam RPL Analisa Resiko Estimasi Biaya Penjadwalan Manajemen proyek Pengecekan Kualitas hasil terkait dengan kualitas yang diinginkan bersama Manajemen Sumber Daya Manusia

76 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

77 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

78 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

79 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)

80 Estimasi Dalam aktifitas utama proyek yaitu perencanaan, dilakukan: Sumber daya manusia (ukuran orang/bulan) Jangka waktu kronologis (Ukuran waktu kalender) Biaya (Ukuran uang Rp)

81 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)

82 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

83 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.

84 Identifikasi resiko Melihat semua resiko sesuai dengan kategori(secara makro). Perkiraan resiko Menyiasati 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

85 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

86 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

87 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

88 Perencanaan Proyek (2) Segitiga proyek (Proyek Triangle) 1. Time Penjadwalan tugas, penentuan durasi, ketergantungan tugas 2. Money Anggaran Belanja, sumber daya 3. Scope Ruang lingkup pekerjaan

89 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

90 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)

91 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

92 Penelusuran dan Pengendalian Penelusuran dan pengendalian dilakukan setelah ada penjadwalan yang pasti, yaitu memeriksa apakah tugas telah dilaksanakan sesuai dengan jadwal.

93 Tujuan Pengukuran Perangkat Lunak Indikasi kualitas produk Perkiraan produktivitas orang-orang yang menghasilkan produk Perkiraan manfaat dari penerapan metode dan tools Membentuk dasar dari estimasi Menegaskan (Justify) permintaan tools baru dan pelatihan

94 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

95 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

96 Komponen Dalam Proyek PL Manager Senior Menentukan isu-isu bisnis yang memiliki pengaruh penting dalam proyek Manager (Teknis) Proyek Merencanakan, memotivasi, mengorganisir dan mengontrol proyek sebuah produk / aplikasi Pelaksana Yang menyampaikan keterampilan teknik yang diperlukan untuk merekayasa sebuah produk / aplikasi

97 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

98 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

99 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

100 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

101 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

102 Æ Á ¹ ¼- ëçñ º ±â»ç ëàú äã»çñ Ù. È-ÀÏ ü ÀÚ Â Àоî  ¹ ¼-ÀÇ Á º ÇØ ç ¹ ¼- ü ¼³Á À» äã»çñ Ù. È- é ü  ÀоîµéÀΠüµé ëçø ÀÌ º Î Á ÄÀ» ½ÃÄÑ È- é º ÁØ Ù. 1: Doc view request ( ) 1: Doc view request ( ) 9: sortbyname ( ) 2: fetchdoc( ) L 3: create ( ) 6: filldocument ( ) 9: sortbyname ( ) 2: fetchdoc( ) 7: readfile ( ) 5: readdoc ( ) 4: create ( ) 8: fillfile ( ) 5: readdoc ( ) 7: readfile ( ) 4: create ( ) 8: fillfile ( ) 3: create ( ) 6: filldocument ( ) FileMgr fetchdoc( ) sortbyname( ) rep Repository (from Persistence) name : char * = 0 readdoc( ) readfile( ) UI DocumentApp Persistence FileList add( ) delete( ) read( ) File DocumentList flist 1 GrpFile read( ) fillfile( ) Document name : int get( ) open( ) sortfilelist( ) create( ) filldocument( ) global MFC RogueWave read() fill the code.. Openning Reading add file [ numberoffile==max ] / flag OFF close file Closing close file add file Writing ºÐ»ê È æàç Çϵå þ¾î¹ ³ Æ À ÎÀÇ Á º ½Ã½ºÅÛ á ðµ - À µµ ì 95 : Å óàì¾ðæ - À µµ ì NT: ÀÀ ë¼-¹ö - À нº Ó½Å: ÀÀ ë ¼-¹ö ¹ µ ÀÌÅ ¼-¹ö, Åë½Å ¼-¹ö - IBM ÞÀÎÇÁ ¹ÀÓ: µ ÀÌÅ ¼-¹ö, Åë½Å ¼-¹ö Window95 ¹ ¼- ü Å óàì¾ðæ.exe Windows NT Windows NT ¹ ¼- ü Áø.EXE Windows95 IBM Mainframe µ ÀÌÅ º À̽º¼-¹ö Solaris ÀÀ ë¼-¹ö.exe Windows95 ¹ ¼- ü ¾ÖÇà Alpha UNIX ARTIFACT UML Use-Case Diagram Class Diagram State Diagram Actor A Use Case 1 Actor B add( ) delete( ) docid : int numfield : int close( ) read( ) Domain Expert Use Case 2 Use Case 3 open( ) create( ) <<entity>> Customer name addr receive() withdraw() fetch() send() Class Deployment Diagram Repository DocumentList User Interface Definition user user :»ç ëàú mainwnd : MainWnd filemgr : FileMgr repository : Repository mainwnd filemgr : FileMgr document : Document gfile repository gfile : GrpFile document : Document Collaboration Diagram Package Diagram GraphicFile FileManager File Component Diagram Document FileList Forward Engineering(Code Generation) and Reverse Engineering Source Code edit, compile, debug, link Sequence Diagram Executable System

103 DIAGRAM-DIAGRAM DI UML Use Case Diagrams Use Case Diagrams Activity Diagrams Use Case Diagrams Use Case Diagrams Use Case Diagrams State Diagrams State Diagrams Class Diagrams State Diagrams State Diagrams Object Diagrams Scenario Diagrams Scenario Diagrams Sequence Diagrams Model State Diagrams State Diagrams State Diagrams Scenario Diagrams Scenario Collaboration Diagrams Diagrams Deployment Diagram Component Diagrams Component Diagrams Component Diagrams

104 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

105 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)

106 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

107 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

108 Tidak boleh ada komunikasi langsung antar actor Indikasi <<system>> 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

109 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

110 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

111 Association antara use case <<include>> termasuk didalam use case lain (required) / (diharuskan) Pemanggilan use case oleh use case lain, contohnya adalah pemanggilan sebuah fungsi program Tanda panah terbuka harus terarah ke sub use case Gambarkan association include secara horizontal Register for courses <<include>> <<include>> Logon validation Maintain curriculum

112 Association antara use case (Lanjut) <<extend>> 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 <<extend>> Nasabah Buka Deposito

113 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

114 Generalization/inheritance antara actor Gambarkan generalization/inheritance antara actors secara vertical dengan inheriting actor dibawah base/parent use case

115 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

116

117 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

118 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

119 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.

120 CONTOH CLASS DIAGRAM

121 MULTIPLICITY Unspecified Exactly one Zero or more (many, unlimited) One or more Zero or one (optional scalar role) Specified range 1 0..* * 1..* Multiple, disjoint ranges 2, 4..6

122 Class Diagram diperoleh berdasarkan dari database Contoh Kasus (Acknowledgments Evi Lutfi Muktar)

123 Contoh Kasus (Acknowledgments Toeko triyanto) pelanggan_reg no int(5) nomor_pelanggan varchar(12) nama_lengkap varchar(20) username varchar(13) password varchar(13) varchar(30) 1 1 cari() simpan() batal() keluhan_pelanggan id int(5) nomor_pelanggan varchar(12) nama_pelanggan varchar(20) varchar(100) keluhan text kode_security varchar(6) simpan() batal() tunggakan nomor_pelanggan varchar(20) tanggal_rekening varchar(15) rupiah_ptl int(15) tagihan_lain_lain int(15) ppn int(12) ppj int(15) materai int(7) total_tagihan int(15) tanggal_bayar varchar(15) n n i_01 nomor_agenda int(5) tgl_agenda varchar(15) nomor_pelanggan varchar(12) nama pelanggan varchar(20) alamat_pelanggan varchar (30) no_ktp varchar(19) no_telpon varchar(13) tarif_lama varchar(2) daya_lama varchar(6) tarif_baru varchar(2) daya_baru varchar(6) peruntukan varchar(20) gardu varchar(20) status varchar(1) simpan() batal() 1 1 n 1 n user id_user varchar(50) password varchar(50) nama_lengkap varchar(100) varchar(100) 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) master_pelanggan nomor_pelanggan varchar(12) nama_pelanggan varchar(20) penunjukan_alamat varchar (2) alamat_pelanggan varchar(18) nomor_bangunan varchar(3) nomor_rt int(3) nomor_rw int(2) golongan_tarif varchar(3) daya int(6) 1 nomor_meter varchar(6) nomor_ktp varchar(20) telpon varchar(13) gardu varchar(20) n 1 n kwitansi nomor_kwitansi int(5) tgl_kwitansi varchar(15) nomor_agenda int(5) nomor_pelanggan varchar(12) bp int(10) ujl int(10) materai int(10) total int(10) status int(1) userid varchar(10) simpan() n batal() tambahkwitansi() cari() perintah_kerja nomor_pk int(5) tgl_pk varhcar(15) no_kwitansi int(5) tgl_kwitansi varchar(15) status int(1) cari() 1 mutasi nomor_mutasi int(5) tgl_mutasi varchar(15) nomor_pk int(5) tgl_pk varchar(15) status int(1) cari() 1 1 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() n 1 master_status nomor_status int(1) keterangan varchar(15)

124 Statechart Diagram.

125 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 :

126 State Notasi State menggambarkan kondisi sebuahentitas, dan digambarkan dengan segiempat yang pinggirnya tumpul dengan nama state didalamnya State1 Transition Initial State Final State 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. 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 menggambarkan ketika objek berhenti memberi respon terhadap sebuah event. Final State digambarkan dengan lingkaran solid didalam sebuah lingkaran kosong. Transition

127 Statechart diagram menggambarkan transisi dan perubahan keadaan (dari satu state ke state lainnya) suatu objek pada sistem sebagai diterima. Pada umumnya statechart akibat dari stimuli yang diagram menggambarkan class memiliki lebih dari satu statechart tertentu (satu class dapat diagram). Dalam UML, state digambarkan berbentuk segiempat dengan sudut membulat dan memiliki nama sesuai kondisinya saat itu. Transisi memiliki kondisi guard yang merupakan antar state umumnya 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 :

128

129 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

130 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

131 State Machine Diagram (Statechart diagram in versi 1.x) State 1 Composite State Kumpulan dari beberapa states State 2 State 3 yang setidaknya dalam sebuah region Orthogonal State, jenis composite state lebih dari 1 region Submachine State 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 Digunakan untuk mendukung konsep encapsulation Sebuah state tidak boleh mempunyai region dan submachine secara bersamaan Nama state mempunyai sintaks : nama submachine state : referenced state machine

132 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

133 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: X<0, X=0 dan X>0 konsisten X<=0 dan X>=0 tidak konsisten Guards harus lengkap logikanya Contoh: X<0 dan X>0, bagaimana jika X=0? Methode dijalankan ketika object memasuki state diindkasikan dengan methode bernama entry( ) ketika object keluar state diindikasikan dengan methode bernama exit( ) Methode menyebabkan perubahan di sebuah state bisa juga tidak

134 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). Dimungkinkan transition ke sebuah state yang berisi beberapa state yang disebut state list State1, State2 Junction, Menggabungkan sebuah/beberapa transition dan memecahnya menjadi sebuah/beberapa transition yang berkondisi AND (transition harus dilewati semuanya). Digunakan tanda lingkaran hitam kecil Contoh:

135 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

136 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

137 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.

138 Contoh State Diagram

139 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.

140 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.

141 Contoh : Component Diagram applet1.class applet1.java Demo.html applet2.class applet2.java logo.gif

142 Contoh : Component & Deployment Diagram

143 Contoh kasus (Acknowledgments Toeko triyanto) state chart diagram pendaftaran statechart diagram pengisian data kwitansi. pengisian data kirim isi ulang data masukan pengisian data kirim isi ulang simpan data masukan simpan

144

145 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

146 Simbol Activity Diagram Simbol Start Point End Point Activities Keterangan Fork (Percabangan) Join (Penggabungan) Decision Swimlane Sebuah cara untuk mengelompokkan activity berdasarkan Actor (mengelompokkan activity dalam sebuah urutan yang sama) Sumber : Rational rose

147 CONTOH ACTIVITY DIAGRAM Penarikan Uang dari Account Bank Melalui ATM

148 CONTOH ACTIVITY DIAGRAM Bagian Gudang Bagian Pembelian Supplier Memberi informasi data Barang yang akan dipesan Menerima informasi Buat SPP Terima SPP Terima Barang dan Faktur Kirim Barang disertai Faktur Buat SPBJ Tandatangani SPBJ Terima SPBJ Melakukan pembayaran Konfirmasi pembayaran Terima pembayaran Terima Kwitansi Buat kwitansi

149

150 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).

151 3. Proses Pengolahan Daftar Data Pegawai dan Gaji (DDPG) Setelah bagian administrasi menerima Rekap Biodata Pegawai (RBP) dan Rekap Absen (RA) akan mengolah kedua data tersebut untuk dibuatkan menjadi Daftar Data Pegawai dan Gaji (DDPG) yang kemudian diserahkan kepada Kepala Sekolah untuk ditanda tangani atau di Acc. 4. Proses Pembuatan Laporan 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.

152 Proses Absensi

153 Acivity Diagram Rekap Biodata Pegawai (RBP)

154 Activity Diagram Pembuatan Daftar Data pegawai dan Gaji (DDPG)

155 Activity Diagram Proses Laporan

156 (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

157 Activity diagram pendaftaran perubahan daya pelanggan pelayanan pelanggan spv pelayanan memberikan fotocopy ktp dan rekening listrik menerima fotocopy ktp dan rekening listrik 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

158 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 spv pelayanan pelanggan memberikan formulir pendaftaran menerima formulir pendaftaran membuat surat persetujuan menyetujui surat persetujuan memberikan surat persetujuan menerima surat persetujuan

159 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 spv pelayanan manager menerima surat persetujuan membuat surat perjanjian jual beli tenaga listrik mencetak surat perjanjian jual beli tenaga listrik memberikan 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 memberikan 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 memberikan surat perjanjian jual beli tenaga listrik menerima surat perjanjian jual beli tenaga listrik

160 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 loket PT PLN melakukan pembayaran menerima pembayaran cetak bukti pembayaran menyetujui bukti pembayaran menerima bukti pembayaran memberikan bukti pembayaran

161 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 penyambungan pelaksana pelanggan cetak perintah kerja menyetujui perintah kerja melakukan penggantian MCB menerima perintah kerja melakukan penggantian MCB memberikan perintah kerja menerima perintah kerja menyetujui perintah kerja menerima perintah kerja memberikan perintah kerja menerima perintah kerja memberikan perintah kerja

162 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.

163 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.

164 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 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.

165 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!

166

167 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).

168 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

169 Simbol Sequence Diagram

170 Contoh Sequence Diagram

171

172

173

174 Contoh kasus Penggajian (Acknowledgments Evi Lutfi Muktar) SEQUENCE DIAGRAM INPUT DATA PEGAWAI

175 SEQUENCE DIAGRAM INPUT DATA PENDIDIKAN

176 SEQUENCE DIAGRAM INPUT DATA KELUARGA

177 SEQUENCE DIAGRAM ABSEN MASUK

178 Contoh kasus PLN (Acknowledgments Toeko triyanto) : administrator : form tambah manajemen user : control form tambah manajemen user open ( ) get username, password nama lengkap, pelanggan display username, password nama lengkap, simpan simpan

179 : pelanggan : form tambah pendaftaran : controlform tambah pendaftaran open ( ) get nomor_pelanggan peruntukan, tarif, daya : pelanggan1 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

180

181 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.

182 Contoh Collaboration Diagram

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

184 Collaboration Diagram (Acknowledgments Toeko triyanto) : simpan : tambah data : info : cari : pendaftaran : batal : pengunjung : index\home : register : simpan : member : index\home : cetak : simpan : manajemen kontrol : tambah modul : login : batal : batal : logout : manajemen modul : hapus : batal : login1 : update : browse : edit : profile : batal : simpan : update : tambah user : manajemen user : cetak : cari : batal : hapus : pendaftaran : tambah data : simpan : update : cari : batal : cari : edit : cetak dokumen : batal : cetak : tambah kwitansi : simpan : login1 : index\home : kwitansi1 : admin : login : perintah kerja1 : cari : cetak : batal : batal : cetak : cari : simpan : tambah guestbook : guestbook1 : data pelanggan1 : manajemen kontrol1 : mutasi1 : peremajaan : batal : hapus : edit : informasi tagihan1 : cari : cari : batal : simpan : batal : cari : cari : cetak : cari : cetak dokumen : tambah kwitansi : simpan : kwitansi1 : user : index\home : cetak : batal : cari : simpan : perintah kerja1 : tambah guestbook : guestbook1 : informasi tagihan1 : mutasi1 : cetak : batal : data pelanggan1 : cari : hapus : edit : cari : cari : batal : peremajaan : simpan : batal

185 PERTEMUAN 6 COMPONENT DIAGRAM

186 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:

187

188 Component Diagram Menggambarkan alokasi semua class dan object kedalam komponen dalam desain fisik system software, termasuk pengaturan dan kebergantungan antar komponen software Component dapat terdiri dari logical component, seperti business component, process component, dll Physical component (software arsitektur), seperti Com+, dot NET,CORBA, dll Component digambarkan dengan bentuk pada UML versi 1.*: Pada UML versi 2 digambarkan dengan bentuk atau atau atau Stereotypes yang dapat digambarkan pada bentuk component <<application>>,kumpulan aplikasi system <<executable>>,component yang jalan di client <<file>>, data file <<infrastructure>>, technical component didalam system <<source code>>, source file <<table>>, table data dalam sebuah database <<UI>>, User interface (screen, pages, report) dll <<database>> <<document>> <<library>> <<web service>> <<XML DTD>>

189 Component Diagram Dependencies dimodelkan dengan garis terputus dengan panah terbuka gambarkan dependencies dari kiri ke kanan Contoh: <<ASP>> Source Code bergantung pada <<database>> MySQL Dimungkinkan sebuah component dependencies pada interfaces component 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 <<UI>> Penjualan <<application>> Pembelian <<application>>

190 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

191 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:

192 Component Diagram (Acknowledgments Toeko triyanto) Simpan database server Kirim Isi data Browsing

193 Deployment Diagram

194 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.

195 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.

196 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, , dll Digambarkan dengan bentuk Dapat dihubungkan dengan component pada component diagram Hanya digambarkan dalam sebuah node perhatikan potongan program dibawah ini yang sesuai dengan artifact yang ada: <! order.asp> <!-- #include file=buka.asp --> <!-- #include file=uler.txt --> <!-- #include file=data.css -->//code style sheet <script src="tgl.js"> //javascript </script>

197 Node - Deployment Diagram Adalah hardware seperti computer/pda,lap top, handphone peralatan komunikasi data (router,hub,switch,modem) dll Digambarkan dengan bentuk kotak 3 dimensi Nama Node Node dapat digabungkan dengan component pada component diagram Node dapat digambarkan dengan bentuk visual, ataupun gabungan antara node dan visual

198 Association (connection) - Deployment Diagram Digambarkan dengan sebuah garis yang menghubungkan antara node Setiap association mempunyai sebuah stereotypes seperti Stereotypes Asychronous HTTP JOBC ODBC RMI RPC Synchronous Web Services Ethernet Istilah Hubungan asynchronous HyperText Transport Protocol (internet protocol_ Java Database Connectivity, a Java API for database access. Open Database Connectivity, a Microsoft API for database access. Remote Method Invocation, a Java communication protocol. Communication via remote procedure calls Komunikasi synchronous Komunikasi melalui Web Services protocols seperti as SOAP and UDDI Ethernet Card Client * <<asynchronous>> 1 Server association dimungkinkan mempunyai multiplicity (0..1, 1..*, dll)

199 Dependencies - Deployment Diagram Digambarkan dengan garis terputus yang berpanah terbuka deploy Sebuah garis terputus dengan ujung panah terbuka yang tertuju ke node dengan sebuah stereotypes <<deploy>> untuk menggambarkan software yang terdapat pada sebuah hardware 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

200 Manifest - Deployment Diagram bentuk fisik dari artifact digambarkan dengan sebuah garis terputus dengan ujung panah terbuka yang tertuju ke component dengan sebuah stereotypes <<manifest>>

201 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, dilambangkan dengan gambar dibawah ini sd Sd = sequence diagram

202 Interaction Overview Diagram Contoh Sequence diagram Interaction overview diagram

203 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 :seminar states proposed, scheduled, enrolling students, Being Taught, Final Exams, Closed Lifeline Timing Constrant {Nov 1.. Des 31} {jan 1.. July 31}

204 Timing Diagram Robust notation State /condition Object Lifeline e Messag

205 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

206 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 dengan berisi nama Role Broker

207 Composite Structure Diagram

208 Contoh Deploment Diagram (Acknowledgments Toeko triyanto) Client Browser Client Browser Client Browser

209 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

210 Contoh package diagram (Acknowledgments Toeko triyanto) tunggakan guestbook keluhan pelanggan kwitansi i_01 perintah_kerja master_pelangg an index/home pelanggan_reg master_status mutasi user. modul Master_tarif

211 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

212 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.

213 Notasi dan Penamaan Untuk Konstruksi Skema Diagram ER No Simbol Keterangan 1. Entity Type Suatu yang ada (secara eksplisit ada) namun keberadaannya dapat nyata dapat virtual, serta perbedaan antar entity harus jelas. Ex. Pegawai, Departemen 2. 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

214 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

215 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

216 7. Derived Attribute Merupakan kombinasi dari attribute-attribute dimana keberadaannya tidak perlu disimpan. Ex. MHS Mata Kuliah E1 8. Identifying Relationship Type Bila entity mempunyai hubungan lebih dari satu entity lain. E1 E2 E2

217 9. Relationship Type Menyatakan hubungan antar attribute sehingga terjadi pemetaan. Ex. Mahasiswa M Bisa Ambi l * * # # # Range # Domain N Mat. Kul Kodomain Hasil Dari Relasi : One To One (1:1) One To Many (1:N) Many To Many (1:M)

218 Derajat Relationship UNARY RELATIONSHIP BINARY RELATIONSHIP N-ARY RELATIONSHIP

219 ENTITY-RELATIONSHIP DIAGRAM PEGAWAI PUNYA JABATAN PEGAWAI MEMPUNYAI JABATAN PEGAWAI DIPUNYAI OLEH JABATAN PROYEK KERJA PEGAWAI PROYEK DIKERJAKAN OLEH PEGAWAI PROYEK MENGERJAKAN PEGAWAI

220 ENTITY-RELATIONSHIP DIAGRAM PEGAWAI 1 1 PUNYA JABATAN PROYEK 1 KERJA M PEGAWAI 1 M 1 1 MHSISWA M IKUT N MT-KULIAH 1 M M 1

221 ENTITY-RELATIONSHIP DIAGRAM PEGAWAI NO-PEG NAMA ALAMAT 1 1 PUNYA NO-PEG KD-JAB JABATAN KD-JAB URAIAN TUNJANGAN PROYEK 1 M KERJA PEGAWAI KD-PROY NM-PROY ANGGARAN KD-PROY NO-PEG NO-PEG NAMA HONOR MHSISWA M IKUT N MT-KULIAH NIM NAMA ALAMAT NIM KD-MATKUL NILAI KD-MATKUL NM-MATKUL SKS

222 ENTITY-RELATIONSHIP DIAGRAM JENIS ENTITY PEGAWAI 1 M ISI ABSEN STRONG ENTITY WEAK ENTITY TIDAK MEMPUNYAI KEY PEGAWAI 1 M ISI ABSEN NO-PEG NAMA ALAMAT NO-PEG TANGGAL JAM-MASUK JAM-PULANG

223 ENTITY-RELATIONSHIP DIAGRAM NO-PEG NAMA GAPOK LAMA-KERJA JABATAN 1 PEGAWAI KERJA PROYEK M M NO-PEG NO-PROY M NO-PROY NAMA-PROY BIAYA NO-PEG KD-BAG PUNYA PAKAI NO-PROY KD-BAR JUMLAH KD-BAG NAMA-BAG 1 BAGIAN N BARANG KD-BAR HARGA-BAR NAMA-BAR

224 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 ,-(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:

225 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

226 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.

227 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

228 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

229 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.

230 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).

231 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.

232 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

233 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

234 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

235 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

236 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 d. binary relationship b. N-ary relationship e. ternary relationship c. M-ary relationship

237 5. Gambar diatas adalah a. unary relationship d. binary relationship b. N-ary relationship e. ternary relationship c. M-ary 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

238 Pertemuan 9 PRINSIP DAN KONSEP DESAIN

239 Pokok Bahasan dalam RPL : Desain PL dan Rekayasa PL Prinsip Desain Konsep Desain Desain Modular Afektif Model Desain Dokumentasi Desain

240 BukuReferensi: Pressman, RS., 2008, Software Engineering: A Practitioner s Approach, New York: McGraw-Hill Sommerville, I, 2007, Software Engineering, Addsion Wesley

241 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

242 DESAINPLDANREKAYASAPL 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.

243 DESAIN PL DAN REKAYASA PL(lanjutan)

244 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.

245 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.

246 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.

247 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.

248 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.

249 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).

250 KONSEP KONSEPDESAIN 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

251 Abstraksi Data

252 Abstraksi Prosedur

253 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.

254 Modularitas Meyer : 5 kriteria mengevaluasi metode desain 1. Dekomposabilitas Modular dekomposisi 2. KomposabilitasModular 3. Kemampuan Pemahaman Modular 4. KontinuitasModular 5. PtoreksiModular

255 Arsitektur PL Shaw dan Garlan: sekumpulan properti sebagai bagian dari desain arsitektural: 1. Properti Struktural spek representasi desain arsitektur ini menentukan komponen-komponensebuahsistem(mis: modul, objek, filter), dan pola komponen-komponen tersebut dipaket dan berinteraksi satu dengan yang lain. Sebagai contoh: objek dipaketuntukenkapsulasibaikdata danprosesyang memanipulasi data dan berinteraksi dengan invokasi method

256 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.

257 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

258 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)

259 Hierarki Kontrol (lanjutan)

260 Partisi Struktural Partisi Vertikal Didesain sehingga pengambilan keputusan dan pekerjaan distratifikasi Modul pengambilan keputusan tetap ada di puncak arsitektur decision-makers workers

261 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 1 function 3 function 2

262 Struktur Data Struktur Data menentukan : Organisasi dan kompleksitas Item Skalar Metode akses Vektor Sekuensial

263 DESAINMODULARAFEKTIF Mudah untuk dibangun, mudah untuk dirubah dan mudah untuk ditetapkan

264 Modularitas Berapakah jumlah modul yang pas untuk desainpl tertentu?

265 Penyembunyian Informasi

266 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

267 Langkah-langkah Refinement

268 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.

269 Indepedensi Fungsi (lanjutan) Modul melakukan tugas: 1. Menghitungdata suplemenyang didasarkanpadadata 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.

270 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

271 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.

272 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

273 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.

274 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.

275 Message

276 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..

277 Model Desain

278 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

279 Elemen Interface

280 Elemen Komponen

281 Elemen Deployment

282 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

283 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

284 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

285 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

286 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

287 Pertemuan 10 METODE DESAIN (1)

288 Pokok Bahasan dalam RPL : Desain Data Desain Arsitektur Proses Desain Arsitektur Pasca Pemrosesan Desain Optimasi Desain Arsitektur

289 BukuReferensi: Pressman, RS., 2008, Software Engineering: A Practitioner s Approach, New York: McGraw-Hill Sommerville, I, 2007, Software Engineering, Addsion Wesley

290 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

291 DESAIN DATA Aktivitaspertama(danbeberapaseringmengatakanyang terpenting) dari4 aktivitas desain yang dilakukan selama RPL. Prinsip-prinsip: 1. Prinsip analisis sistematik yang diaplikasikan pada fungsi dan perilaku seharusnya diaplikasikan juga pada data. 2. Semua struktur data dan operasi yang dilakukan pada masing-masing struktur data harusdiidentifikasi. 3. Kamusdata harusdibangundandigunakan untukmenentukanbaikdata maupun desain program. 4. Keputusan desain data tingkat rendah harus ditunda sampai akhir proses desain. 5. Representasi stuktur data hanya boleh diketahui oleh modul-modul yang harus menggunakan secara langsung data yang diisikan didalam struktur terseb ut. 6. Pustaka struktur data dan operasi yang berguna yang dapat diaplikasikan pada struktur data tersebut harus dikembangan. 7. Desain PL dan bahasa pemrograman harus mendukung spesifikasi dan realisasi dari tipe-tipe data absktrak.

292 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.

293 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 menggunakanpengukurandesaindanheuristik.

294 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.

295 Karakteristik Aliran

296 PEMETAAN TRANSFORMASI Serangkaian langkah desain yang mengijinkan sebuah DFD dengan karakteristikalirantransformasiuntukdipetakankedalamtempalteyang 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 heuristikdesainbagikualitasperangkatlunakyang telahditingkatkan.

297 PEMETAAN TRANSFORMASI (LANJUTAN) a b d e f g h c data flow model i j x1 "Transform" mapping x2 x3 x4 b c d e f g i a h j

298 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.

299 PEMETAAN TRANSAKSI (lanjutan) Program Architecture

300 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).

301 Pendekatan: OPTIMASI DESAIN ARSITEKTUR 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. Bilaperlu, desainulangataukodekankembalibahasayang tergantung pada mesin untuk meningkatkan efisiensi.

302 Pertemuan 11 METODE DESAIN (2)

303 Pokok Bahasan dalam RPL : Desain Interface Desain Interface Manusia Mesin Desain Prosedural Coding

304 BukuReferensi: Pressman, RS., 2008, Software Engineering: A Practitioner s Approach, New York: McGraw-Hill Sommerville, I, 2007, Software Engineering, Addsion Wesley

305 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

306 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

307 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

308 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.

309 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.

310 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.

311 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.

312 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.

313 DESAIN INTERFACE MANUSIA MESIN (lanjutan) - Siklus evaluasi desain interface Desain Permulaaan Membuat Prototipe Interface #n Membuat Prototipe Interface #1 Modifikasi desain dilakukan Pemakai mengevaluasi interface Desain Interface dilengkapi Evaluasi dipelajari oleh desainer

314 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.

315 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.

316 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.

317 DESAIN PROSEDURAL Terjadi setelah data, desain arsitektur dan interface dibangun. Pemrograman Terstruktur Urutan Kondisi (langkah pemrosesan yang penting dalam spesifikasi sembarang algoritma). (fasilitas bagi pemrosesan yang dipilih berdasarkan beberapa kejadian logis). Pengulangan (menyediakan looping)

318 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.

319 DESAIN PROSEDURAL (lanjutan) Langkah untuk mengembangkan tabel keputusan: 1. Daftarkan semua aksi yang dapat diasosiasikan dengan sebuah prosedur tertentu(atau modul). 2. Daftarkansemuakondisi(ataukeputusanyang dibuat) selama eksekusi prosedur. 3. Hubungkan serangkaian kondisi tertentu dengan aksi tertentu, denganmengeliminasikombinasidarikondisiyang mungkin. 4. Tentukanaturan-aturandenganmenunjukkanaksi, apayang terjadi bagi serangkaian kondisi.

320 DESAINPROSEDURAL (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. Fasilitasdeklarasidata yang harusmeliputistrukturdata kompleks(linked list) dan sederhana(skalar, array). 4. Definisisubprogram danteknikpemanggilanyang mendukung berbagai mode deskripsi interface.

321 CODING

322 Pertemuan 12 IMPLEMENTASI

323 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

324 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

325 Makna & Tujuan Implementasi (2) Melibatkan pengintegrasian semua komponen rancangan sistemtermasuk PL, konversi ke sistem operasi. Proses implementasi melibatkan: Perencanaan Pengeksekusian

326 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

327 Contoh Rencana Implementasi

328 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)

329 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.

330 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

331 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

332 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.

333 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

334

335 Hal Penting Dalam Implementasi (7) Penjelasan Tanpa dokumentasi yang jelas dan akurat Pengembangan sistem

336 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

337 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

338 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

339 Memberikan derajat proteksi yang tinggi dari kegagalan sistem baru Biaya yang dibutuhkan cukup besar karena harus jalan bersama-sama keduanya

340 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

341 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

342 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

343 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

344 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

345 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.

346 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

347 5. Efisiensi Kriteria Lingkungan Pemrograman (2) 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

348 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 yang bervariasi untuk aplikasi yang kompleks 11. Ketersediaan Tool Pembangunan Semua peralatan terintegrasi dalam satu interface

349 Kriteria Lingkungan Pemrograman (4) 12. Kebijakan Instansi (Tim) Pemilihan bahasa pemrograman ditentukan oleh institusi (tim) atau oleh penggunanya 13. Kebutuhan Eksternal Adanya tambahan alat baru atau PL baru yang harus terhubung dengannya

350 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

351 PERTEMUAN 13 STRATEGI PENGUJIAN PERANGKAT LUNAK

352 Strategi uji coba perangkat lunak dilakukan untuk memudahkan para perancang untuk menentukan keberhasilan system yang telah dikerjakan

353 Proses Testing Unit Testing Module Testing Sub-system Testing System Testing Acceptance Testing Component Testing Integration Testing User Testing 3

354 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 yang membentuk suatu sub-system (aplikasi) 4

355 Proses Testing System Testing Pengujian terhadap integrasi sub-system, yaitu keterhubungan antar sub-system 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

356 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.

357 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