PERTEMUAN 1 REKAYASA PERANGKAT LUNAK

Transkripsi

1 PERTEMUAN 1 REKAYASA PERANGKAT LUNAK

2 Pertemuan 1 PENGENALAN REKAYASA PERANGKAT LUNAK Pokok Bahasan dalam RPL : RPL sebagai produk dan sebagai produk Konsep manajemen proyek Proses pembangunan PL dan metrik proyek Perencanaan proyek PL Manajemen resiko dlm pelaksanaan proyek Penjadwalan dan penelusuran proyek pembangunan PL Jaminan kualitas PL Manajemen konfigurasi PL Rekayasa sistem ke arah CB Pokok Bahasan dalam RPL (lanjutan) Konsep dan prinsip analisis Pemodelan analisis Konsep dan prinsip desain Metode desain Implementasi pembangunan Teknik pengujian perangkat Strategi perancangan PL CASE tool pembangunan PL Buku Referensi : Pressman, RS., 2008, Software Engineering: A Practitioner s Approach, New York: McGraw-Hill Sommerville, I, 2007, Software Engineering, Addsion Wesley Rekayasa Perangkat Lunak Perangkat Lunak? (Software??) Rekayasa Perangkat lunak-rpl? (Software engineering-se??) Rekayasa sistem-rs? (system engineering-sye??) Evolusi Perangkat Lunak Computer Science vs RPL RPL vs RS?? Pelaku yang berhubungan dengan Rekayasa Perangkat Lunak Mitos yang ada berkembang Tantangan dalam Pengembangan Perangkat Lunak Definisi Perangkat Lunak (PL) IEEE-Standar Glossary of Software Engineering Terminology, 1990: Computer programs, procedures, and possibly associated documentation and data pertaining to the operation of a computer system. Maksudnya : Perangkat lunak merupakan kumpulan dari program, prosedur, dan dokumen data lain yang saling berhubungan yang merepresentasikan masalah di dunia nyata yang dikonfigurasikan dalam sebuah bentuk aplikasi yang harus dikerjakan komputer Produk Perangkat Lunak Perangkat lunak tidak sama dengan produk perangkat keras Produk perangkat lunak dikembangkan (developed) atau direkayasa (engineered). Sebagian besar dikembangkan atau dibangun berdasrkan pemesanan dan sebagian kecil dibuat secara paket. Tidak dipabrikkan seperti pabrik perangkat keras, misal komputer, mobil. Perangkat lunak secara pemakaian tidak pernah AUS layaknya perangkat keras Produk Perangkat Lunak (2) 2 Bentuk produk perangkat lunak: 1. Produk Generik (Umum) Sistem stand-alone standar yang diproduksi oleh organisasi pengembang dan dijual ke pasar terbuka ke siapapun yg membelinya. Biasa disebut sebagai software shrink-wrapped. Contoh : word processor, Database. 2. Produk pesanan (yang disesuaikan) Sistem yang dipesan oleh pelanggan tertentu. Dikembangkan khusus bagi pelanggan oleh kontraktor perangkat lunak. Contoh : Sistem untuk mendukung proses bisnis tertentu dan sistem kontrol lalu lintas udara Produk Perangkat Lunak (3) Perbedaan PENTING antara 2 bentuk perangkat lunak : Pada produk generik, mengembangkan perangkat spesifikasi perangkat lunak. organisasi yang lunak mengontrol

3 Pada produk pesanan, spesifikasi biasanya dikembangkan dan dikontrol oleh organisasi yang membeli perangkat lunak tersebut. Produk Perangkat Lunak (4) Karakteristik perangkat lunak yang baik: Usability : Mempunyai daya guna yang tinggi be reliable : Mampu diandalkan maintenability : Mudah dirawat/diperbaiki Efficiency : perangkat perangkat lunak tidak boros dalam menggunakan sumber daya sistem seperti memory & processor eye cathcing user interface : Mempunyai antarmuka yg menarik long life time : Mempunyai siklus hidup yang cukup lama Mempunyai kinerja sesuai fungsi yang dibutuhkan pemakai Jenis-jenis aplikasi Perangkat Lunak Perangkat Lunak Sistem (System software) Adalah sekumpulan program yang ditulis untuk melayani atau menunjang program lainnya. Misalnya : compiler, editor, komponen-komponen sistem operasi, driver dan prosesor telekomunikasi. Perangkat lunak waktu nyata (Realtime Software) Perangkat lunak yang berfungsi untuk memonitor, menganalisis, mengontrol dan memberikan laporan tentang kejadian dunia nyata dan meresponnya dalam waktu kurang dari 1 menit. Misal: pengontrol arus udara, pengontrol keasaman tabung reaksi (pressman punya), pengontrol reaksi nuklir, dll Jenis-jenis aplikasi Perangkat Lunak (2) Perangkat Lunak Teknik Dan (Scientific & Engineering Software) Ilmu Pengetahuan Perangkat lunak yg menangani bidang teknik dan ilmu pengetahuan secara rinci Misal: simulasi astronomi, vulkanologi, analisis otomatif, dinamika orbit pesawat ruang angkasa, biologi molekuler, otomasi pabrik, dll Embeded System Perangkat lunak yg ditempelkan/dilekatkan pada perangkat lainnya (lunak/keras). Misal: pada kamera digital, GPS, automobil, microwave, kulkas cerdas, dll Jenis-jenis aplikasi Perangkat Lunak (3) Perangkat Lunak Pengolah Data (Data Processing) Perangkat lunak yg khusus digunakan untuk mengolah data dan menghasilkan suatu keputusan tertentu. Misal: billing telepon, pengolah statistik Perangkat System) Lunak Sistem Informasi (Information Perangkat lunak yg mampu memberi informasi dari suatu sistem secara lebih detail. Misal: web site, perpustakaan digital, dll Jenis-jenis aplikasi Perangkat Lunak (4) Perangkat Lunak Sensor Perangkat lunak yg mampu mengukur dan mengatur suatu keadaan khusus, kadang digolongkan dalam embedded system juga. Misal: pengatur cuaca, pengatur suhu ruangan, dll Perangkat Software)

4 Lunak Komunikasi (Communicaion Perangkat lunak yg berfungsi untuk menghubungkan atau mengkomunikasikan suatu objek satu dengan lainnya. Misal: router, handphone, dll Jenis-jenis aplikasi Perangkat Lunak (5) Perangkat Lunak Pengolah Grafis Perangkat lunak yang digunakan untuk melakukan perancangan grafis Misal: pembuatan film, pembuatan poster Perangkat Lunak Kecerdasan Perangkat lunak yg menggunakan algoritma no-numeris untuk memecahkan masalah kompleks yg tdk sesuai untuk perhitungan atau analisis secara langsung Misal: sistem pakar, pembuktian teorema, game strategi, jaringan saraf tiruan, dll Evolusi Perangkat Lunak Perangkat lunak telah semakin berkembang sejak pertama kali diciptakan tahun 1945 Fokus utama pembuatannya untuk mengembangkan praktik dan teknologi dalam meningkatkan produktivitas para praktisi pengembang PL dan kualitas aplikasi yg dapat digunakan oleh pemakai Evolusi dipicu adanya tuntutan bisnis dan lingkungan kerja yang berkembang sangat dinamis Evolusi Perangkat Lunak (2) Era I ( ): Munculnya teknologi perangkat keras di tahap awal Penggunaan perangkat lunak yg berorientasi batch Distribusi perangkat lunak masih terbatas Didominasi perangkat lunak model custome Munculnya istilah software engineering (akhir 1950an/awal 1960-an) Belum didefinisikan secara jelas tentang aspek software engineering Evolusi Perangkat Lunak (3) Era II ( ) Disebut era krisis perangkat lunak (software crisis). Penggunaan perangkat lunak sudah meluas Telah hadir perusahaan yang membangun software (software house) Perangkat lunak sdh mengenal multiprogram, multiuser, real-time, dan penggunaan database. Evolusi Perangkat Lunak (4) Era II (Lanjutan) Banyak project PL yg gagal Over budget/anggaran Berakibat rusak fisik dan kematian Meledaknya Roket Ariane, kesalahan perintah dlm PL Dua konferensi ttg software engineering: Disponsori Komite Sains NATO Tahun 1968 dan 1969 Profesi resmi bidang software engineering Evolusi Perangkat Lunak (5) Era III ( ) Pengembangan sistem mengarah ke konsep sistem terdistribusi. Penerapan sistem embeded intelligence Harga perangkat keras sudah jauh lebih murah sehingga pemakaian meluas Pemanfaatan jaringan global dan lokal serta sudah diperkenalkan komunikasi digital Evolusi Perangkat Lunak (6) Era IV ( ) Kemampuan PC sudah setara dengan komputer mainframe Penerapan teknologi yang berorientasi pada objek Implementasi sistem pakar Jaringan saraf tiruan Komputasi paralel Jaringan komputer sudah semakin canggih Evolusi Perangkat Lunak (7) Era V (2000 sekarang) Penggunaan media digital Media web berkembang pesat Wireless sudah meluas Teknologi meluas hingga di mobile computing, mobile programming Perangkat keras sudah semakin kecil namun powerfull Dilakukan berbagai penelitian yang menghasilkan model proses/paradigma pengembangan PL utk mengatasi krisis PL

5 Krisis Perangkat Lunak Masalah yang muncul: Estimasi jadwal dan biaya yang seringkali tidak tepat Produktivitas orang-orang software yang tidak dapat mengimbangi permintaan software Kualitas software yang kurang baik. Kurangnya pengetahuan tentang: Bagaimana mengembangkan software Bagaimana memelihara software berkembang dalam jumlah besar yang ada, yang Bagaimana mengimbangi permintaan software yang makin besar. Mitos Dalam Perangkat Lunak (Management) Mitos1: Kita tidak perlu mengubah pendekatan terhadap pengembangan software, karena jenis pemrograman yang kita lakukan sekarang ini sudah kita lakukan 10 tahun yang lalu. Realitasnya : Walau hasil program sama, produktivitas dan kualitas software harus ditingkatkan dengan menggunakan pendekatan software developments Mitos Dalam Perangkat Lunak (Management) (2) Mitos2: Kita sudah mempunyai buku yang berisi standarisasi dan prosedur untuk pembentukan software. Realitasnya : Memang buku tersebut ada, tetapi apakah buku tersebut sudah dibaca atau buku tersebut sudah ketinggalan jaman ( out of date ). Mitos3: Jika kita tertinggal dari jadwal yang ditetapkan, kita menambah beberapa programmer saja. Konsep ini sering disebut Mongolian harde concept. Mitos dalam perangkat lunak (Customer) Mitos1: Pernyataan tujuan umum sudah cukup untuk memulai penulisan program. Penjelasan yang lebih rinci akan menyusul kemudian. Realitasnya : Definisi awal yang buruk adalah penyebab utama kegagalan terhadap usaha-usaha pem-bentukkan software. Penjelasan yang formal dan terinci tentang informasi fungsi performance interface, hambatan desain dan kriteria validasi adalah penting. Karakteristik di atas dapat ditentukan hanya setelah adanya komunikasi antara customer dan developer. Mitos dalam perangkat lunak (Customer) Mitos2: Kebutuhan proyek yang terus menerus berubah dapat dengan mudah diatasi karena software itu bersifat fleksibel. Realitasnya : memang benar bahwa kebutuhan software berubah, tetapi dampak dari peru-bahan berbeda dari waktu ke waktu. Mitos Dalam Perangkat Lunak (Praktisi) Mitos1: Tidak ada metode untuk analisis disain dan testing terhadap suatu pekerjaan, cukup menuju ke depan terminal dan mulai coding. Realitasnya : Metode untuk analisis desain dan testing diperlukan dalam pengembangan software. Mitos2: Segera setelah software digunakan, pemeliharaan dapat diminimalisasikan dan diatasi dengan cara CATCH AS CATCH CAM. Realitasnya : Diperlukan budget yang besar dalam maintenance software. Pemeliharaan software harus diorganisir, direncanakan dan dikontrol seolah-olah sebagai suatu proyek besar dalam sebuah organisasi. Mitos dalam perangkat lunak (Management) Mitos2: Kebutuhan proyek yang terus menerus

6 berubah dapat dengan mudah diatasi karena software itu bersifat fleksibel. Realitasnya : memang benar bahwa kebutuhan software berubah, tetapi dampak dari peru-bahan berbeda dari waktu ke waktu. Definisi Rekayasa Perangkat Lunak (RPL) RPL atau Software Engineering (SE) Disiplin ilmu yang membahas semua aspek produksi perangkat lunak, mulai dari tahap awal spesifikasi sistem sampai pemeliharaan sistem setelah digunakan. Perangkat Lunak yang dibuat harus mampu: Tepat waktu Tepat anggaran Meningkatkan kinerja Mengoperasikan prosedur sistem dengan benar Definisi Rekayasa Perangkat Lunak (Lanjutan) Ada 2 istilah kunci : 1. disiplin rekayasa Perekayasa membuat suatu alat bekerja. Menerapkan teori, metode, dan alat bantu yang sesuai, selain itu mereka menggunakannya dengan selektif dan selalu mencoba mencari solusi terhadap permasalahan. 2. semua aspek produksi perangkat lunak RPL tidak hanya berhubungan dengan proses teknis dari pengembangan perangkat lunak tetapi juga dengan kegiatan seperti Manajemen proyek PL dan pengembangan alat bantu, metode, dan teori untuk mendukung produksi PL. Perbedaan RPL dengan Computer science Computer science lebih memperhatikan teori & metode komputerisasi, sedangkan software engineering menyangkut masalah praktikal pembuatan dan delivery perangkat lunak Software engineering merupakan bagian dari system engineering, dimana sistem engineering memperhatikan semua aspek pembuatan sistem berbasis komputer termasuk perangkat keras, perangkat lunak & proses Perbedaan RPL dengan Rekayasa Sistem (RS)? Rekayasa Sistem (RS) berkaitan dengan semua aspek dalam pembangunan sistem berbasis komputer termasuk hardware, rekayasa PL dan proses. RPL adalah bagian dari rekayasa sistem yang meliputi pembangunan PL, infrasktruktur, kontrol, aplikasi dan database pada sistem. Tantangan dalam Rekayasa Perangkat Lunak Tantangan warisan Dikembangkan bertahun-tahun dengan orang-orang yang berbeda-beda Tantangan heterogensis Dalam hal distribusi & teknologi Tantangan pengiriman Bagaimana mengirim sistem yang besar dan kompleks cepat dan dengan kualitas tetap terjaga. Pelaku Dalam RPL Manajer Manajer proyek Manajer konfigurasi Manajer penjamin kulitas PL Manajer bidang lainnya (sesuai kebutuhan Software Developer Analis sitem Desainer Programmer Inspektor PL Pengontrol perubahan Pelaku Dalam RPL (Lanjutan) Pendukung Staf administrasi Humas Pencatat teknis Administrator database Administrator jaringan Pertemuan 2 SOFTWARE DEVELOPMENT LIFE CYCLE (SDLC) POKOK BAHASAN Biaya PL Software Quality Attribute Standar kualitas Takaran Jaminan Kualitas CASE TOOLS Siklus Hidup Perangkat Lunak (SWDLC/Software Development Life Cycle)

7 BIAYA PERANGKAT LUNAK (SOFTWARE COST) Terkadang mendominasi biaya sistem secara keseluruhan Biaya terbesar untuk perangkat lunak terletak pada proses perawatan (maintenance) dibanding biaya pembuatannya (develop) Biaya pengadaan perangkat lunak yang di pasang pada PC sering lebih besar dibandingkan dengan harga perangkat kerasnya kec. Di negara-negara yang tidak menghargai HAKI Biaya perangkat lunak secara kasar sebesar 60% dari biaya untuk pembangunan dan 40% untuk pengujian Secara umum besarnya biaya bervariasi tergantung pada tipe sistem yang dibangun dan kebutuhan sistem seperti kinerja dan kehandalan sistem Biaya distribusi tergantung pada model pembangunan yang digunakan SOFTWARE QUALITY ATTRIBUTE (1) Ciri-ciri kualitas menurut lembaga penjamin mutu PL (ISO, ANSI, IEEE, dll): Correctness (kebenaran) Kesesuaian antara kode program dg spesifikasi Kebebasan aplikasi aktual pada sistem PL Reliability (tahan uji) Didasari pada (ketersediaannya) correctness dan availability Sebagai suatu kemungkinan bahwa sistem ini mampu memenuhi suatu kegunaan (tergantung spesifikasinya) untuk sejumlah masukan percobaan di bawah kondisi masukan dan rentang waktu yang telah ditentukan. 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) UKURAN JAMINAN KUALITAS (1) Ukuran membangun (constructive measures) Aplikasi yg konsisten pada metode di seluruh fase proses pembangunan Penggunaan perlatan/ tools yang memadai Pembangunan PL pd basis kualitas yg tinggi di akhir tahapan Perawatan yang konsisten pada dokumenasi pengembangan Ukuran analitik (analytical measures) Analisis program yang statis Analisis program yang dinamis Pemeilihan test case yang sistematis Pencatatan yang konsisten pada analisis produk UKURAN JAMINAN KUALITAS (2) Ukuran Organisasi (Organization Measures) Pengalaman pengembang (developer) dalam mempelajari strategi dan teknik yang tepat dalam membangun PL KRISIS PERANGKAT LUNAK Masalah yang muncul: Estimasi jadwal dan biaya yang seringkali tidak tepat Produktivitas orang-orang software yang tidak dapat mengimbangi permintaan software Kualitas software yang kurang baik. Kurangnya pengetahuan tentang: Bagaimana mengembangkan software Bagaimana memelihara software yang ada, yang berkembang dalam jumlah besar Bagaimana mengimbangi permintaan software yang makin besar. KODE ETIK PROFESI Konfidensialitas (menghormati klien) Tidak boleh menerima pekerjaan di luar kompetensinya Hak kekayaan intelektual (HaKI) Penyalahgunaan komputer, hack, crack, KODE ETIK INTERNASIONAL Digagas oleh masyarakat profesional di Amerika (1999) yang tergabung dalam ACM/IEEE Makna yang terkandung: Prinsip-prinsip kesepakatan yang dihubungkan dengan tingkah laku dan keputusan yang dibuat oleh para ahli profesional Masyarakat profesional: praktisi, pengajar, manajer, supervisor, pengambil kebijakan. Yang diatur:

8 Masyarakat dan kepentingannya Klien dan atasan (pelayanan terbaik) Produk (jaminan mutu) Manajemen Profesi Kolega Diri sendiri (ada usaha untuk mengupdate ipteknya) CASE TOOLS CASE (Computer Aided Software Engineering) Suatu peralatan baik HW maupun SW komputer yang digunakan untuk menyediakan pendukung otomatis dalam aktivitas pembangunan PL. Tujuan meningkatkan produktivitas dalam proses pembangunan PL secara signifikan Dikelompokkan dalam 2 kategori: 1. Upper-CASE Mendukung aktivitas proses pembangunan tahap awal (tahap analisis kebutuhan dan desain) 2. Lower-CASE Mendukung aktivitas pembangunan di tahap akhir programming, debuging, dan testing) CASE TOOLS (2) Penggunaan CASE tools: Graphical Editors Digunakan untuk membuat model sistem Data Dictionaries Digunakan untuk mengatur unit-unit proyek GUI Builders Digunakan untuk mengkonstruksi antarmuka pemakai Debugger Digunakan untuk mencari kesalahan yg mungkin terjadi Automated Translators Digunakan untuk pembangkitan source code program otomatis Compilator Integrated Digunakan membuat antarmuka, koding, hingga membentuk aplikasi yg bisa dijalankan Instalator Kit Digunakan untuk membuat file instalasi/setup SOFTWARE DEVELOPMENT LIFE CYCLE (SDLC) Proses Generik Spesifikasi Apa yang harus dilakukan oleh perangkat lunak dan batasan/kendala pengembangannya Pengembangan Proses memproduksi sistem perangkat lunak Validasi Pengujian perangkat lunak terhadap keinginan pengguna Evolusi Perubahan perangkat lunak berdasarkan perubahan keinginan. MODEL PROSES RPL Model Waterfall, Model Prototyping, Model Evolutionary Model Spiral Reuse Based Development WATERFALL MODEL Requirement Definitions Pemodelan Sistem/ Informasi System and software design Implementation and unit testing Integr ation and system testing Operation and maintenance WATERFALL MODEL (2) Requirements Analysis And Definition Pembentukan kebutuhan System And Software Design Mengubah kebutuhan-kebutuhan menjadi karakteristik yang dimerngerti perangkat lunak Implementation And Unit Testing Penulisan program Integration And System Testing Memeriksa program, mencari kesalahan Operation And Maintenance Pemeliharaan sistem, menambahkan fungsi bentuk WATERFALL MODEL (3) Problems Model Waterfall 1. Jarang sekali proyek yang prosesnya bisa dilakukan secara sequencial. 2. Sukar bagi customer untuk secara mengemukakan semua kebutuhannya. explisit 3. Customer harus sabar. 4. Developer sering menunda pekerjaan. Anggota tim harus menunggu anggota lainnya 5. menyelesaikan tugasnya. PROTOTYPE MODEL Membangun Konstruksi (prototipe) Mendengarkan Pelanggan

9 Uji Pelanggan (evaluasi) PROTOTYPE MODEL (2) Prototype Paradigm dimulai dengan mengumpulkan kebutuhankebutuhan customer. Developer dan customer bertemu dan mendefinisikan obyektif software secara menyeluruh, mengidentifikasi kebutuhan-kebutuhan yang diketahui dari area pekerjaan. Setelah itu dibuat Quick Design. Quick Design difokuskan pada representasi aspek software yang bisa dilihat customer/user (misal: format input dan output). Quick Design cenderung ke pembuatan prototipe. Prototipe dievaluasi customer/user dan digunakan untuk menyempurnakan kebutuhan software yang akan dikembangkan. PROTOTYPE MODEL (2) Sering terjadi customer menjabarkan objektif umum mengenai software yang diminta, tetapi tidak bisa mendefinisakan input, proses, output yang diminta secara detail. Disisi lain, developer menjadi tidak yakin terhadap efisiensi algoritma, kemampuan adaptasi terhadap sistem operasi, atau bentuk interaksi mesin dengan orang. Untuk mengatasi situasi tersebut, bisa digunakan pendekatan Prototype Paradigm. PROTOTYPE MODEL (3) Problems Prototyping Model Customer melihat prototipe tersebut sebagai versi dari software. Pada saat produk tersebut harus dibangun ulang supaya level kualitas bisa terjamin, Customer akan mengeluh dan meminta sedikit perubahan saja supaya prototipe tersebut bisa berjalan. Development membuat implemetasi yang kompromitas dengan tujuan untuk memperoleh prototipe pekerjaan secara cepat. Dampaknya adalah sistem operasi atau bahasa pemrograman yang dipergunakan tidak tepat, algoritma tidak efisien. EVOLUTIONARY MODEL EVOLUTIONARY MODEL INCREMENTAL (2) Penjelasan : 1. Kombinasikan elemet-element dari waterfall dengan sifat iterasi/perulangan. 2. Element-element dalam waterfall hasil berupa produk dengan dikerjakan dengan 3. Spesifikasi tertentu, kemudian proses dimulai dari fase pertama hingga akhir dan menghasilkan produk dengan spesifikasi yang lebih lengkap dari yang sebelumnya. 4. Demikian seterusnya hingga semua spesifikasi memenuhi kebutuhan yang ditetapkan oleh pengguna. EVOLUTIONARY MODEL INCREMENTAL (3) 5. Produk hasil increment pertama biasanya produk inti (core product), yaitu produk yang memenuhi kebutuhan dasar. Produk tersebut digunakan oleh pengguna atau menjalani review/ pengecekan detil. Hasil review tersebut menjadi bekal untuk pembangunan pada increment berikutnya. Hal ini terus dikerjakan sampai produk yang komplit dihasilkan. 6. Model ini cocok jika jumlah anggota tim pengembang/pembangun PL tidak cukup. 7. Mampu mengakomodasi perubahan secara fleksibel. 8. Produk yang dihasilkan pada increment pertama bukanlah prototype, tapi produk yang sudah bisa berfungsi dengan spesifikasi dasar. EVOLUTIONARY MODEL INCREMENTAL (4) Kekurangan Incremental Model: Hanya cocok untuk proyek berukuran kecil (tidak lebih dari baris coding) Mungkin terjadi kesulitan untuk memetakan kebutuhan pengguna ke dalam rencana spesifikasi masingmasing hasil increment EVOLUTIONARY MODEL SPIRAL

10 EVOLUTIONARY MODEL SPIRAL (2) Penjelasan : Customer Comunication Membangun komunikasi yang baik dengan pelanggan Planning Mendefinisikan sumber, batas waktu, informasiinformasi lain seputar proyek Risk Analyst Identifikasi resiko management dan teknis Engineering Pembangunan contoh-contoh aplikasi misalnya prototype Construction and release Pembangunan, test, install dan report Customer Evaluation Mendapatkan feedback dari pengguna berdasarkan evaluasi pada fase engineering dan fase instalasi EVOLUTIONARY MODEL SPIRAL (3) Pada model spiral, resiko sangat dipertimbangkan. Resiko adalah sesuatu yang mungkin mengakibatkan kesalahan. Model spiral merupakan pendekatan yang realistik untuk Perangkat Lunak berskala besar. Pengguna dan pembangun bisa memahami dengan baik software yang dibangun karena setiap kemajuan yang dicapai selama proses dapat diamati dengan baik. Namun demikian, waktu yang cukup panjang mungkin bukan pilihan bagi pengguna, karena waktu yang lama sama dengan biaya yang lebih besar. REUSE BASED A. Software Re-engineering Apakah itu? Restrukturisasi atau menulis ulang sebagian atau keseluruhan dari sistem yang telah ada tanpa merubah fungsionalitasnya. Kapan? Ketika sebagian tetapi tidak semua sub sistem yg besar membutuhkan perawatan yg sering Ketika HW dan SW sudah lama hampir tak berfungsi Bagaimana? Sistem bisa di restrukturisasi dan didokumentasi ulang untuk membuat menjadi mudah dalam perawatan REUSE BASED (2) Software Re-engineering (lanjutan) Mengapa? Mengurangi resiko SW yang baru dibangun membawa resiko yg tinggi Mengurangi biaya Biaya untuk re-engineering sering lebih kecil dibanding membangun SW baru. REUSE BASED (3) REUSE BASED (3) B. Reverse Engineering Analisis SW kembali dalam tahap pemahaman dlm desain dan spesifikasinya Bisa sebagian proses re-engineering atau sebagian spesifikasi sistem untuk diimplementasi ulang Membangun database dan bangkitkan program informasi dari proses ini Mengapa? Kode aslinya telah dalam keterbatasan dimana sudah terlalu lama, misal kebutuhan memori, kinerja, dll Perawatan terbentur pada struktur dan program yang rusak sehingga membutuhkan kerja yg sangat keras Program secara otomatis distrukturisasi ulang untuk menghilangkan beberapa bagian yang tidak beres dalam kondisi yang sangat kompleks. Pertemuan 3 Manajemen Proyek Perangkat Lunak Proses Dalam Manajemen PL Manajemen proyek merupakan lapisan pertama dalam proses rekayasa perangkat lunak skala besar. Untuk menuju pada proyek yang berhasil, perlu dimengerti tentang : Lingkup pekerjaan Resiko yang dapat ditimbulkan Sumber-sumber yang diperlukan Tugas yang harus dilaksanakan Patokan yang harus diikuti Usaha atau biaya yang dikeluarkan Dan Penjadwalan Langkah Awal dalam Manajemen Perangkat Lunak Untuk mengestimasi biaya, pembagian tugas,

11 penjadwalan, sebelum sebuah proyek direncanakan : Memastikan tujuan dan ruang lingkup Memperhatikan alternatif-alternatif solusi Identifikasi batasan teknik dan manajerial dan Fokus Manajemen Proyek Manajemen proyek terfokus pada 4P, yaitu : 1. People Elemen terpenting dalam keberhasilan suatu proyek 2. Product Perangkat lunak yang dihasilkan 3. Process Sekelompok aktivitas kerangka kerja dalam merekayasa perangkat lunak 4. Project Seluruh proses yang dibutuhkan untuk menghasilkan suatu produk Faktor-faktor yang mempengaruhi hasil akhir proyek Perangkat Lunak Ukuran (size) Batas waktu pengiriman (Delivery Deadline) Pembiayaan dan anggaran (Budgets & Costs) Bidang aplikasi (Application Domain) Implementasi Teknologi (Technology Can Be Implemented) Batasan-batasan sistem (System Constrains) Kebutuhan pengguna (User Requirements) Sumber daya yang tersedia (Available Resource) Permasalahan Dalam Manajemen Proyek Bagaimana kualitas produk yang akan dihasilkan Perkiraan / beban resiko yang timbul Ukuran perangkat lunak Estimasi / perkiraaan dana Penjadwalan proyek Komunikasi dengan pelanggan Tim perancang Sumber daya lainnya Proses monitoring proyek Fokus Dalam RPL Analisa Resiko Estimasi Biaya Penjadwalan Manajemen proyek Pengecekan Kualitas hasil terkait dengan kualitas yang diinginkan bersama Manajemen Sumber Daya Manusia Pengukuran Perangkat Lunak Pengukuran dan satuan ukuran akan membantu untuk mengerti proses-proses dalam pengembangan dan produk itu sendiri. Proses dan produk diukur untuk meningkatkan kualitasnya. usaha Pengukuran Perangkat Lunak (2) 1. Pengukuran Langsung Terkait dengan biaya dan usaha yang diaplikasikan, misalnyayang menyangkut deretan kode program, kecepatan eksekusi, ukuran memori yang dibutuhkan dan cacat pada produk, yang dilaporkan pada sejumlah periode waktu 2. Pengukuran tidak Langsung Terkait dengan fungsionalitas, kualitas, kompleksitas, efisiensi, reabilitas, kemampuan pemeliharaan dan lainlain Pengukuran Perangkat Lunak (3) Mengapa perangkat Lunak Harus Diukur?? 1. Untuk mengetahui karakteristik Perangkat Lunak 2. Proses evaluasi Perangkat Lunak 3. Prediksi kebutuhan Perangkat Lunak 4. Pengembangan Perangkat Lunak Pengukuran Perangkat Lunak (4) Kualitas Pengukuran Perangkat Lunak : Correctness Sesuai dengan spesifikasi yang diinginkan Maintability Kemudahan pemeliharaan dan stabil Integrity Daya tahan terhadap serangan dari luar sistem Usability Kemudahan dalam penggunaan (userfriendly) Estimasi Dalam aktifitas dilakukan: utama proyek

12 yaitu perencanaan, Sumber daya manusia (ukuran orang/bulan) Jangka waktu kronologis (Ukuran waktu kalender) Biaya (Ukuran uang Rp) Estimasi (2) A. Tujuan Perencanaan Anggaran Proyek Untuk menjalankan apa yang telah ditentukan dalam tahap planning Memberikan arah/dukungan financial untuk membiayai proyek Untuk mengontrol dan mendokumentasikan pembiayaan proyek B. Metode Perencanaan Anggaran Metode perkiraan (intuisi) pimpinan dan tim Taksiran standar TCA(Traditional Cost Accounting) ABC (Activity Based Costing) Estimasi (3) Beberapa hal yang terkait dengan metode ABC : Konsistensi lebih akurat dibandingkan dengan metode TCA Terkonsentrasi pada biaya tidak langsung (tambahan) Biaya selalu berhubungan dengan aktifitas Aktifitas selalu menggunakan sumber daya Mengkonversi biaya langsung menjadi tidak langsung Analisis Resiko Analisis resiko merupakan serangkaian langkah untuk menyiasati resiko Analisis resiko sangat penting dalam manajemen proyek perangkat lunak. Beberapa hal yang harus diperhatikan berkaitan dengan resiko adalah: Masa yang akan datang, Perubahan, Pilihan. Menyiasati Resiko Identifikasi resiko Melihat semua resiko sesuai dengan kategori(secara makro). Perkiraan resiko Memperhitungkan lebih lanjut estimasi resiko. Proyeksi resiko Disebut juga estimasi resiko, adalah usaha untuk mengukur setiap resiko. Strategi manajemen resiko Putusan (Resolution) resiko Pemantauan resiko Pengendalian Resiko Strategi Penanganan Resiko 1. Manajemen Resiko Reaktif Tim proyek beraksi pada resiko mereka menjumpainya Pelonggaran rencana penambahan resource antisipasi, misalnya kebakaran Perbaikan pada kesalahan, sumber daya yang ditemukan & diterapkan ketika resiko sudah menyerang Manejemen krisis kesalahan tidak dapat direspon oleh sumber daya & menjadi ancaman bagi keberlangsungan proyek Pengendalian Resiko (2) 2. Manajemen Resiko Proaktif Kinerja analisis resiko secara formal Koreksi terorganisasi pada penyebab resiko Pengujian sumber resiko yang diantaranya adalah perangkat lunak Pengembangan kemampuan untuk mengatur perubahan Perencanaan Proyek Memahami masalah yang akan di hadapi Menentukan cara-cara yang tepat untuk mendapatkan solusi yang tepat Pengoptimalan efisiensi dan keuntungan proyek Memerlukan dokumen kebutuhan yang akan digunakan untuk pengambilan keputusan menerima proyek/menolaknya. Jika menerima maka langkah selanjutnya adalah membuat proposal Perencanaan Proyek (2) Segitiga proyek (Proyek Triangle) 1. Time Penjadwalan tugas, penentuan

13 ketergantungan tugas 2. Money Anggaran Belanja, sumber daya 3. Scope Ruang lingkup pekerjaan durasi, Perencanaan Proyek (3) Strategi Perencanaan memilih dan menerapkannya Hasil tujuan Asumsi/anggapan Pembatasan Area/cakupan berhubungan dengan tugas dan pengiriman Tahapan perencaan Proyek Penentuan area/cakupan proyek Pendefinisian tugas-tugas, teknik/tools (WBS, project Network Diagram) Pendefinisian sumber daya Penjadwalan teknik/tools : PERT, CPM, Gantt Chart Penentuan Anggaran Perencanaan Proyek (4) Tools dan Teknik Manajemen Proyek Work Breakdown Structure Project Network Diagram Critical Path Method (CPM) Program Evaluation and Review Technique (PERT) Gantt Chart Precedence Diagramming Method (PDM) Penjadwalan Langkah-langkah yang dilakukan dalam penjadwalan: 1. Identifikasi sekumpulan tugas 2. Pastikan keterkaitan antar tugas 3. Estimasi usaha untuk tiap-tiap tugas 4. Tentukan pekerja dan sumber-sumber lainnya 5. Buat jaringan tugas 6. Buat jadwal kerja berdasarkan waktu Penelusuran dan Pengendalian Penelusuran dan pengendalian dilakukan setelah ada penjadwalan yang pasti, yaitu memeriksa apakah tugas telah dilaksanakan sesuai dengan jadwal. Tujuan Pengukuran Perangkat Lunak Indikasi kualitas produk Perkiraan produktivitas menghasilkan produk orang-orang yang Perkiraan manfaat dari penerapan metode dan tools Membentuk dasar dari estimasi Menegaskan (Justify) permintaan tools baru dan pelatihan Ukuran Kualitas Perangkat Lunak Kualitas perangkat lunak dihitung pada saat proses rekayasa perangkat lunak ataupun setelah diserahkan kepada pemakai. Satuan ukuran kualitas perangkat lunak pada saat proses rekayasa : 1. Kompleksitas program 2. Modularitas yang efektif 3. Besarnya program Penyebab Kegagalan (PL) Penyebab kegagalan sebuah proyek PL : Batas waktu pengerjaan proyek yang tidak realistis Perubahan keinginan pelanggan Meremehkan pekerjaan Munculnya resiko yang dapat diperkirakan dan resiko yang diluar perkiraan Kesulitan secara teknis Kesalahpahaman antara anggota tim proyek Kesalahan dalam manajemen proyek Komponen Dalam Proyek PL Manager Senior Menentukan isu-isu bisnis yang memiliki pengaruh

14 penting dalam proyek Manager (Teknis) Proyek Merencanakan, memotivasi, mengorganisir mengontrol proyek sebuah produk / aplikasi dan Pelaksana Yang menyampaikan keterampilan teknik yang diperlukan untuk merekayasa sebuah produk / aplikasi Komponen Dalam Proyek PL (2) Pelanggan Menentukan jenis kebutuhan akan perangkat lunak yang akan direkayasa Pemakai Akhir (end-user) Yang berinteraksi dengan perangkat lunak bila perangkat lunak telah dipublikasikan (release) untuk digunakan Komponen Dalam Proyek PL (3) Faktor yang harus dipertimbangkan dalam menyeleksi tim pelaksana proyek 1. Tingkat kesulitan dari masalah yang akan dikerjakan 2. Ukuran program yang dihasilkan yang terkait dengan jumlah fungsi yang digunakan 3. Waktu yang dibutuhkan oleh tim untuk bekerja secara bersama-sama 4. Tingkatan dimana masalah dapat dimodularisasi / dibuat dalam bentuk modul Komponen Dalam Proyek PL (4) 5. Kualitas yang diperlukan serta keandalan sistem yang dibangun 6. Kepastian tanggal penyampaian ke pelanggan 7. Memiliki kemampuan sosialisasi (komunikasi) yang dibutuhkan dalam proyek Definisi Masalah dalam RPL 1. Menetapkan Ruang Lingkup Permasalahan : Konteks Bagaimana software yang akan dibangun nantinya dapat memenuhi kebutuhan sistem serta batasan yang ditentukan oleh sistem Tujuan Informasi Menentukan objek data yang dihasilkan sebagai output dan object data yang diperlukan sebagai input Fungsi dan Unjuk Kerja Menentukan fungsi yang akan dilakukan untuk mentransformasi input data menjadi output serta ciri kerja khusus yang akan ditekankan Definisi Masalah dalam RPL (2) 2. Dekomposisi masalah Menetapkan pembagian fungsi / aktivitas kerja pada 2 area utama, yaitu ; Fungsionalitas yang harus disampaikan Proses yang akan dipakai untuk menyampaikannya ARTIFACT UML Use-Case Diagram Class Diagram State Diagram Document add( ) delete( ) name : int docid : int numfield : int get( ) open( ) close( ) read( ) sortfilelist( ) create( ) filldocument( ) FileList Use Case 1 flist add( ) delete( ) Actor A

15 Writing add file [ numberoffile==max ] / flag OFF read() fill the code.. Openning close file 1 Actor B close file Reading Closing rep Use Case 2 File Repository (from Persistence) read( ) <> Customer name addr receive() withdraw() fetch() send() GrpFile name : char * = 0 Domain Expert add file DocumentList FileMgr fetchdoc( ) sortbyname( ) read( ) open( ) create( ) fillfile( ) readdoc( ) readfile( ) Use Case 3 Deployment Diagram UI Class

16 MFC DocumentApp ºÐ»ê È æàç Çϵå þ¾î¹ ³ Æ À ÎÀÇ Á º ½Ã½ºÅÛ á ðµ - À µµ ì 95 : Å óàì¾ðæ - À µµ ì NT: ÀÀ ë¼-¹ö - À нº Ó½Å: ÀÀ ë ¼-¹ö ¹ µ ÀÌÅ ¼-¹ö, Åë½Å ¼-¹ö - IBM ÞÀÎÇÁ ¹ÀÓ: µ ÀÌÅ ¼-¹ö, Åë½Å ¼-¹ö RogueWave Repository Persistence 9: sortbyname ( ) DocumentList Windows95 Window95 Windows95 global ¹ ¼- ü Å óàì¾ðæ.exe FileManager ¹ ¼- ü ¾ÖÇà mainwnd : MainWnd 1: Doc view request ( ) Windows NT L 2: fetchdoc( ) gfile : GrpFile 4: create ( ) 8: fillfile ( ) user :»ç ëàú User Interface Definition filemgr : FileMgr 3: create ( ) 6: filldocument ( ) Package Diagram Document Solaris

17 ¹ ¼- ü Áø.EXE Alpha UNIX ÀÀ ë¼-¹ö.exe Windows NT GraphicFile File IBM Mainframe FileList µ ÀÌÅ º À̽º¼-¹ö 7: readfile ( ) 5: readdoc ( ) document : Document repository : Repository Collaboration Diagram mainwnd user Æ Á ¹ ¼- ëçñ º ±â»ç ëàú äã»çñ Ù. filemgr : FileMgr document : Document gfile repository Component Diagram Forward Engineering(Code Generation) and Reverse Engineering Source Code edit, compile, debug, link 1: Doc view request ( ) 2: fetchdoc( ) 3: create ( ) 4: create ( ) 5: readdoc ( ) È-ÀÏ ü ÀÚ Â Àоî  ¹ ¼-ÀÇ Á º ÇØ ç ¹ ¼ ü ¼³Á À» äã»çñ Ù. 6: filldocument ( ) 7: readfile ( ) 8: fillfile ( ) È- é ü  ÀоîµéÀΠüµé ëçø ÀÌ º Î Á ÄÀ» ½ÃÄÑ È- é º ÁØ Ù.

18 9: sortbyname ( ) Sequence Diagram Executable System DIAGRAM-DIAGRAM DI UML Use Case Use Case Diagrams Activity Diagrams Diagrams Scenario Scenario Diagrams Sequence Diagrams Diagrams Scenario Scenario Diagrams Collaboration Diagrams Diagrams Use Case Use Case Diagrams Use Case Diagrams Diagrams State State Diagrams Class Diagrams Diagrams Model Deployment Diagram State State Diagrams Object Diagrams Diagrams State State Diagrams State Diagrams Diagrams Component Component Diagrams Component Diagrams Diagrams USE CASE DIAGRAM Menggambarkan fungsionalitas yang diharapkan dari sebuah sistem. Yang ditekankan adalah apa yang diperbuat sistem, dan bukan bagaimana. Menggambarkan kebutuhan system dari sudut pandang user Mengfokuskan pada proses komputerisasi (automated processes) Menggambarkan hubungan antara use case dan actor Use case menggambarkan proses system (kebutuhan system dari sudut pandang user) Secara umum use case adalah: Pola perilaku system Urutan transaksi yang berhubungan yang dilakukan oleh satu actor Use case diagram terdiri dari a. Use case b. Actors c. Relationship d. System boundary boxes (optional) e. Packages (optional) Deskripsi Use case Diagram Use case Use case dibuat berdasar keperluan actor, merupakan apa yang dikerjakan system, bukan bagaimana system mengerjakannya Use case diberi nama yang menyatakan apa hal yang dicapai dari hasil interaksinya dengan actor. Use case dinotasikan dengan gambar (horizontal ellipse) Use case biasanya menggunakan kata kerja Nama use case boleh terdiri dari beberapa kata dan tidak boleh ada 2 use case yang memiliki nama yang sama Simbol use case ACTOR Actor menggambarkan orang, system atau external entitas / stakeholder yang menyediakan atau menerima informasi dari system Actor menggambarkan sebuah tugas/peran dan bukannya posisi sebuah jabatan Actor memberi input atau menerima informasi dari system Actor biasanya menggunakan Kata benda Simbol actor Tidak boleh ada komunikasi langsung antar actor Indikasi <> untuk sebuah actor yang

19 merupakan sebuah system Adanya actor bernama Time yang mengindikasikan scheduled events (suatu kejadian yang terjadi secara periodik/bulanan) Letakkan actor utama anda pada pojok kiri atas dari diagram Association Associations bukan menggambarkan aliran data/informasi Associations digunakan untuk menggambarkan bagaimana actor terlibat dalam use case Ada 4 jenis relasi yang bisa timbul pada use case diagram 1. Association antara actor dan use case 2. Association antara use case 3. Generalization/Inheritance antara use case 4. Generalization/Inheritance antara actors Association antara actor dan use case Ujung panah pada association antara actor dan use case mengindikasikan siapa/apa yang meminta interaksi dan bukannya mengindikasikan aliran data Sebaiknya gunakan Garis tanpa panah untuk association antara actor dan use case association antara actor dan use case yang menggunakan panah terbuka untuk mengindikasikan bila actor berinteraksi secara pasif dengan system anda Association antara use case <> termasuk didalam use case lain (required) / (diharuskan) Pemanggilan use case oleh use case lain, contohnya adalah pemanggilan sebuah fungsi program Tanda panah terbuka harus terarah ke sub use case Gambarkan association include secara horizontal <> Register for courses <> Logon validation Maintain curriculum Association antara use case (Lanjut) <> perluasan dari use case lain jika kondisi atau syarat terpenuhi Kurangi penggunaan association Extend ini, terlalu banyak pemakaian association ini membuat diagram sulit dipahami. Tanda panah terbuka harus terarah ke parent/base use case Gambarkan association extend secara vertical Buka Rekening <> Nasabah Buka Deposito Generalization/inheritance antara use case Generalization/inheritance digambarkan dengan sebuah garis berpanah tertutup pada salah satu ujungnya yang menunjukkan lebih umum Gambarkan generalization/inheritance antara use case secara vertical dengan inheriting use case dibawah base/parent use case Generalization/inheritance dipakai ketika ada sebuah keadaan yang lain sendiri/perlakuan khusus (single condition) Buka Rekening Nasabah Buka Deposito Generalization/inheritance antara actor Gambarkan generalization/inheritance antara actors secara vertical dengan inheriting actor dibawah base/parent use case Use case System boundary boxes Digambarkan dengan kotak disekitar use case, untuk menggambarkan jangkauan system anda (scope of of your system). Biasanya digunakan apabila memberikan beberapa alternative system yang dapat dijadikan pilihan System boundary boxes dalam penggunaannya optional

20 CLASS DIAGRAM Class adalah sebuah spesifikasi yang jika diinstansiasi akan menghasilkan sebuah objek dan merupakan inti dari pengembangan dan desain berorientasi objek. Class menggambarkan keadaan (atribut/properti) suatu sistem, sekaligus menawarkan layanan untuk memanipulasi keadaan tersebut (metoda/fungsi). Class diagram menggambarkan struktur dan deskripsi class, package dan objek beserta hubungan satu sama lain seperti containment, pewarisan, asosiasi, dan lain-lain. Class memiliki tiga area pokok : 1.Nama, merupakan nama dari sebuah kelas 2. Atribut, merupakan peroperti dari sebuah kelas. Atribut melambangkan batas nilai yang mungkin ada pada obyek dari class 3. Operasi, adalah sesuatu yang bisa dilakukan oleh sebuah class atau yang dapat dilakukan oleh class lain terhadap sebuah class CLASS DIAGRAM (LANJUTAN) Atribut dan metoda dapat memiliki salah satu sifat berikut : Private, tidak dapat dipanggil dari luar class yang bersangkutan Protected, hanya dapat dipanggil oleh class yang bersangkutan dan anak-anak yang mewarisinya Public, dapat dipanggil oleh siapa saja Package, hanya dapat dipanggil oleh instance sebuah class pada paket yang sama Nama Class Atribut Metode/operasi HUBUNGAN ANTAR CLASS 1. Asosiasi, yaitu hubungan statis antar class. Umumnya menggambarkan class yang memiliki atribut berupa class lain, atau class yang harus mengetahui eksistensi class lain. Panah navigability menunjukkan arah query antar class. 2. Agregasi, yaitu hubungan yang menyatakan bagian ( terdiri atas.. ). 3. Pewarisan, yaitu hubungan hirarkis antar class. Class dapat diturunkan dari class lain dan mewarisi semua atribut dan metoda class asalnya dan menambahkan fungsionalitas baru, sehingga ia disebut anak dari class yang diwarisinya. Kebalikan dari pewarisan adalah generalisasi. 4. Hubungan dinamis, yaitu rangkaian pesan (message) yang di-passing dari satu class kepada class lain. Hubungan dinamis dapat digambarkan dengan menggunakan sequence diagram yang akan dijelaskan kemudian. CONTOH CLASS DIAGRAM MULTIPLICITY Unspecified Exactly one Zero or more (many, unlimited) 1 0..* * One or more Zero or one (optional scalar role) Specified range Multiple, disjoint ranges 1..* , 4..6 Class Diagram diperoleh berdasarkan dari database Contoh Kasus (Acknowledgments Evi Lutfi Muktar) 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 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) n tarif_baru varchar(2) daya_baru varchar(6) peruntukan

21 varchar(20) gardu varchar(20) status varchar(1) 1 cari() simpan() batal() 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 1 1 n modul id_modul int(5) nama_modul varchar(50) link varchar(100) static_content text gambar varchar(100) publish enum('y','n') status enum('user','admin','umum') aktif enum('y','n') urutan int(5) simpan() batal() 1 user id_user varchar(50) password varchar(50) nama_lengkap varchar(100) varchar(100) 1 bagian varchar(100) referensi varchar(100) level varchar(50) master_tarif nomor int(5) peruntukan varchar(10) tarif varchar(2) daya varchar(10) bp int(10) ujl int(10) materai int(10) simpan() batal() keluhan_pelanggan id int(5) nomor_pelanggan varchar(12) nama_pelanggan varchar(20) varchar(100) keluhan text kode_security varchar(6) kwitansi n n 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) 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) n

22 simpan() n batal() tambahkwitansi() cari() 1 1 perintah_kerja nomor_pk int(5) tgl_pk varhcar(15) no_kwitansi int(5) tgl_kwitansi varchar(15) status int(1) cari() mutasi nomor_mutasi int(5) tgl_mutasi varchar(15) nomor_pk int(5) tgl_pk varchar(15) status int(1) cari() 1 n 1 master_status nomor_status int(1) keterangan varchar(15) Statechart Diagram. Statechart diagram, atau yang biasa juga disebut state diagram digunakan untuk mendokumentasikan beragam kondisi/keadaan yang bisa terjadi terhadap sebuah class dan kegiatan apa saja yang dapat merubah kondisi/keadaan tersebut. Contohnya sebuah televisi yang dapat berada dalam kondisi menyala atau mati, jika tombol power ditekan maka televisi akan menyala, begitu juga sebaliknya akan mati jika tombol power ditekan kembali. Maka disini kita mempunyai sebuah kelas yaitu televisi, 2 state yaitu menyala dan mati dan 2 transition yaitu menyalakan TV dan mematikan TV. Tidak seperti diagram-diagram behavioural lainnya yang memodelkan interaksi diantara beberapa class, state diagram justru biasanya hanya memodelkan transisi yang terjadi hanya pada sebuah class. Berikut adalah notasi state diagram : State Transition Notasi State menggambarkan kondisi sebuahentitas, dan digambarkan dengan segiempat yang pinggirnya tumpul dengan nama state didalamnya Sebuah Transition menggambarkan sebuah perubahan kondisi objek yang disebabkan oleh sebuah event. Transition digambarkan dengan sebuah anak panah dengan nama event yang ditulis diatasnya, dibawahnya atau sepanjang. anak panah tersebut Initial State sebuah kondisi awal sebuah object sebelum ada perubahan keadaan. Initial State digambarkan dengan sebuah lingkaran solid. Hanya satu Initial State yang diizinkan dalam sebuah diagram Final State menggambarkan ketika objek berhenti memberi respon terhadap sebuah event. Final State digambarkan dengan lingkaran solid didalam sebuah lingkaran kosong. State1 State1

23 Transition Statechart diagram menggambarkan transisi dan perubahan keadaan (dari satu state ke state lainnya) suatu objek pada sistem sebagai akibat dari stimuli yang diterima. Pada umumnya statechart diagram menggambarkan class tertentu (satu class dapat memiliki lebih dari satu statechart diagram). Dalam UML, state digambarkan berbentuk segiempat dengan sudut membulat dan memiliki nama sesuai kondisinya saat itu. Transisi antar state umumnya memiliki kondisi guard yang merupakan syarat terjadinya transisi yang bersangkutan, dituliskan dalam kurung siku. Action yang dilakukan sebagai akibat dari event tertentu dituliskan dengan diawali garis miring. Titik awal dan akhir digambarkan berbentuk lingkaran berwarna penuh dan berwarna setengah. Contoh statechart diagram : State Machine Diagram (Statechart diagram in versi 1.x) Untuk memodelkan behavior/methode (lifecycle) sebuah kelas atau object Memperlihatkan urutan kejadian sesaat (state) yang dilalui sebuah object, transisi dari sebuah state ke state lainnya State Machine Diagram (Statechart diagram in versi 1.x) Sebuah state machine diagram mempunyai : state (kejadian sesaat) are represented by the values of attributes of an object State digambarkan dengan bentukdata Kosong atau Black Hole states is state has transitions into it but none out Miracle states is state has transitions out of it but none into it initial state / creation state dengan tanda Untuk memulai sebuah state machine diagram (in western culture people read from left to right, top to bottom, starting in the top-left corner) Final state dengan tanda Untuk mengakhiri sebuah state machine diagram Letakkan pada pojok kanan bawah(in western culture people read from left to right, top to bottom, starting in the top-left corner) Simple State Sebuah State yang tidak mempunyai Sub States/region/submachines State Machine Diagram (Statechart diagram in versi 1.x) State 1 Composite State Digunakan untuk Kumpulan dari mendukung konsep beberapa states State 2 State 3 encapsulation yang setidaknya Sebuah state tidak boleh dalam sebuah mempunyai region dan region submachine secara Orthogonal State, bersamaan jenis composite Nama state mempunyai state lebih dari 1 sintaks : region nama submachine state : Submachine State referenced state machine Sejenis composite state yang isinya didefinisikan oleh state machine lain State Machine yang berisi submachine state disebut Containing state machine Sebuah state yang dihubungkan ke state machine lainnya Dihubungkan ke satu/lebih entry point dan satu/lebih exit point State Machine Diagram (Statechart diagram in versi 1.x) Sub States Sebuah state yang ada dalam sebuah region Direct Substate, Sub state yang tidak berisi state lain Indirect Substate, Sub state yang berisi state lain Region (kelompok state) Dipisahkan dengan garis terputus, yang setiap region boleh mempunyai nama sebagai optional Sebuah state tidak boleh mempunyai region dan submachine secara bersamaan State terpisah menjadi 3 bagian yaitu Activity label bisa berupa Entry, Exit atau do Dimana Activity expression adalah penggunaan atribut NIP Kosong Entry/isi NIP Exit/ Help/Tekan F1 Klik Double klik Nama State Internal Activity, kegiatan yang dilakukan dalam state sintaks : Activity label/activity expression Internal transition State Machine Diagram (Statechart diagram in versi 1.x) Transition digambarkan dengan tanda anak panah progressions from one state to another, will be triggered by an event Transition adalah hasil dari methode yang menyebabkan perubahan state, walaupun tidak semua methode menyebabkan perubahan state

24 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 State Machine Diagram (Statechart diagram in versi 1.x) Join, menggabungkan beberapa transition menjadi sebuah transition Fork, memecah sebuah transition menjadi beberapa transition yang berkondisi AND (transition harus dilewati semuanya). Junction, Menggabungkan sebuah/beberapa transition dan memecahnya menjadi sebuah/beberapa transition yang berkondisi AND (transition harus dilewati semuanya). Digunakan tanda lingkaran hitam kecil Contoh: Dimungkinkan transition ke sebuah state yang berisi beberapa state yang disebut state list State1, State2 State Machine Diagram (Statechart diagram in versi 1.x) Choice, Mengkondisikan sebuah transition menjadi sebuah/beberapa transition, yang hanya dipilih salah satu transition(choice). Digunakan lambang diamond Operand dapat diletakkan didalam diamond atau pada transition Contoh: Entry point Dilambangkan sebuah lingkaran kecil yang ditaruh pada pinggiran state(bisa juga didalam atau diluar), dan berguna sebagai submachine state Exit point Dilambangkan sebuah lingkaran kecil bersilang yang ditaruh pada pinggiran state (bisa juga didalam atau diluar), dan berguna sebagai submachine state State Machine Diagram (Statechart diagram in versi 1.x) State Machine Diagram ada 2 jenis Behavioral State Machines Merupakan state machine diagram umumnya Digunakan untuk mendefinisikan perilaku sebuah object Protocol State Machines Digunakan untuk penggunaan protocol pada sebuah system Dapat didefinisikan ke spesifik Protocol State Machines atau ke Behavioral State Machines Didefinisikan sebagai diagram context (global overview) Notasi yang digunakan sama dengan Behavioral State Machines dengan penambahan kata {protocol} Tidak adanya internal activity seperti entry,exit,do Transition pada Protocol State Machines harus menggunakan Protocol Transition Protocol Transition Sintaks : [pre condition] event / [post condition] precondition atau postcondition adalah guard (Guard is condition that must be true for the transition to be triggered) Precondition, kondisi sebelum transition Postcondition, kondisi setelah transition Statechart diagram Statechart diagram menggambarkan transisi dan perubahan keadaan (dari satu state ke state lainnya) suatu objek pada sistem sebagai akibat dari stimuli yang diterima. Pada umumnya statechart diagram menggambarkan class tertentu (satu class dapat memiliki lebih dari satu statechart diagram). Dalam UML, state digambarkan berbentuk segi empat dengan sudut membulat dan memiliki nama sesuai kondisinya saat itu. Transisi antar state umumnya memiliki kondisi guard yang merupakan syarat terjadinya transisi yang bersangkutan, dituliskan dalam