Pertemuan 1 REKAYASA PERANGKAT LUNAK

Pertemuan 1

PENGENALAN

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

Perencanaan proyek PL

Manajemen resiko dlm pelaksanaan proyek

Penjadwalan dan penelusuran proyek pembangunan PL

Jaminan kualitas PL

Manajemen konfigurasi PL

Pokok Bahasan dalam RPL (lanjutan)

Konsep dan prinsip analisis

Pemodelan analisis

Konsep dan prinsip desain

Metode desain

Metode desain

Implementasi pembangunan

Teknik pengujian perangkat

Strategi perancangan PL

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

Buku Referensi :

• 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

 Evolusi Perangkat Lunak

 Computer Science vs RPL

 RPL vs RS ??

 Pelaku yang berhubungan dengan Rekayasa Perangkat Lunak

 Mitos yang ada berkembang

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

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 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 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, organisasi yang mengembangkan perangkat lunak mengontrol spesifikasi perangkat lunak.

 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 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 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, 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 Misal: billing telepon, pengolah statistik

 Perangkat Lunak Sistem Informasi (Information System)

Perangkat lunak yg mampu memberi informasi dari suatu sistem secara lebih detail.

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.

Jenis-jenis aplikasi Perangkat Lunak (5)

 Perangkat Lunak Pengolah Grafis

Perangkat lunak yang digunakan untuk melakukan perancangan grafis

Misal: pembuatan film, pembuatan poster 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 para praktisi pengembang PL dan kualitas aplikasi yg dapat digunakan oleh pemakai

 Evolusi dipicu adanya tuntutan bisnis dan lingkungan kerja yang berkembang sangat dinamis

Evolusi Perangkat Lunak (2)

Era I (1945 – 1960):

 Munculnya teknologi perangkat keras di tahap awal

 Penggunaan perangkat lunak yg berorientasi batch

 Distribusi perangkat lunak masih terbatas

 Distribusi perangkat lunak masih terbatas

 Didominasi perangkat lunak model custome

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

 Belum didefinisikan secara jelas tentang aspek– software engineering

Evolusi Perangkat Lunak (3)

Era II (1960 – 1970)

 Disebut era krisis perangkat lunak (software crisis).

 Penggunaan perangkat lunak sudah meluas

 Telah hadir perusahaan yang membangun software

 Telah hadir perusahaan yang membangun software (software house)

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

Evolusi Perangkat Lunak (4)

Era II (Lanjutan)

 Banyak project PL yg gagal

 Over budget/anggaran

 Berakibat rusak fisik dan kematian

 Berakibat rusak fisik dan kematian

 Meledaknya Roket Ariane , kesalahan perintah dlm PL

 Dua konferensi ttg software engineering:

 Disponsori Komite Sains NATO

 Tahun 1968 dan 1969

Evolusi Perangkat Lunak (5)

Era III (1975 – 1985)

 Pengembangan sistem mengarah ke konsep sistem terdistribusi.

 Penerapan sistem embeded intelligence

 Penerapan sistem embeded intelligence

 Harga perangkat keras sudah jauh lebih murah sehingga pemakaian meluas

 Pemanfaatan jaringan global dan lokal serta sudah diperkenalkan komunikasi digital

Evolusi Perangkat Lunak (6)

Era IV (1985 – 2000)

 Kemampuan PC sudah setara dengan komputer mainframe

 Penerapan teknologi yang berorientasi pada objek

 Penerapan teknologi yang berorientasi pada objek

 Implementasi sistem pakar

 Jaringan saraf tiruan

 Komputasi paralel

Evolusi Perangkat Lunak (7)

Era V (2000 – sekarang)

 Penggunaan media digital

 Media web berkembang pesat

 Wireless sudah meluas

 Wireless sudah meluas

 Teknologi meluas hingga di mobile computing, mobile programming

 Perangkat keras sudah semakin kecil namun powerfull

 Dilakukan berbagai penelitian yang menghasilkan model proses/paradigma pengembangan PL utk mengatasi krisis PL

Krisis Perangkat Lunak

Masalah yang muncul:

 Estimasi jadwal dan biaya yang seringkali tidak tepat

 Produktivitas orang-orang software yang tidak dapat

 mengimbangi permintaan software

 Kualitas software yang kurang baik.

Kurangnya pengetahuan tentang:

 Bagaimana mengembangkan software

 Bagaimana memelihara software yang ada, yang berkembang dalam jumlah besar

 Bagaimana mengimbangi permintaan software yang makin besar.

Mitos1:

 Kita tidak perlu mengubah pendekatan terhadap pengembangan software, karena jenis pemrograman yang kita lakukan sekarang ini sudah kita lakukan 10

Mitos Dalam Perangkat Lunak

(Management)

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

Mitos2:

 Kita sudah mempunyai buku yang berisi standarisasi dan prosedur untuk pembentukan software.

 Realitasnya : Memang buku tersebut ada, tetapi apakah

Mitos Dalam Perangkat Lunak

(Management) (2)

 Realitasnya : Memang buku tersebut ada, tetapi 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.

Mitos1:

 Pernyataan tujuan umum sudah cukup untuk memulai penulisan program. Penjelasan yang lebih rinci akan menyusul kemudian.

Mitos dalam perangkat lunak (Customer)

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.

Mitos2:

 Kebutuhan proyek yang terus menerus berubah dapat dengan mudah diatasi karena software itu bersifat fleksibel.

Mitos dalam perangkat lunak (Customer)

fleksibel.

 Realitasnya : memang benar bahwa kebutuhan software berubah, tetapi dampak dari peru-bahan berbeda dari waktu ke waktu.

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.

Mitos Dalam Perangkat Lunak (Praktisi)

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.

Mitos2:

 Kebutuhan proyek yang terus menerus berubah dapat dengan mudah diatasi karena software itu bersifat fleksibel.

 Realitasnya : memang benar bahwa kebutuhan software

Mitos dalam perangkat lunak (Management)

 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:

harus mampu:

 Tepat waktu

 Tepat anggaran

 Meningkatkan kinerja

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

•

Computer science lebih memperhatikan teori

& metode komputerisasi, sedangkan software

engineering menyangkut masalah praktikal

pembuatan dan delivery perangkat lunak

Perbedaan RPL dengan Computer science

pembuatan dan delivery perangkat lunak

•

Software engineering merupakan bagian dari

system engineering, dimana sistem

engineering memperhatikan semua aspek

pembuatan sistem berbasis komputer

termasuk perangkat keras, perangkat lunak &

proses

Perbedaan RPL dengan Rekayasa Sistem (RS)?

Rekayasa Sistem (RS) berkaitan dengan semua 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 warisan

Dikembangkan bertahun-tahun dengan orang-orang yang berbeda-beda

 Tantangan heterogensis

Dalam hal distribusi & teknologi

Tantangan dalam Rekayasa Perangkat Lunak

Dalam hal distribusi & teknologi

 Tantangan pengiriman

Bagaimana mengirim sistem yang besar dan kompleks cepat dan dengan kualitas tetap terjaga.

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

Pendukung

1. Staf administrasi 2. Humas

3. Pencatat teknis

4. Administrator database

Pelaku Dalam RPL (Lanjutan)

4. Administrator database 5. Administrator jaringan

Pertemuan 2

SOFTWARE DEVELOPMENT

SOFTWARE DEVELOPMENT

POKOK BAHASAN

Biaya PL

Software Quality Attribute

Standar kualitas

Takaran Jaminan Kualitas

Takaran Jaminan Kualitas

CASE TOOLS

Siklus

Hidup

Perangkat

Lunak

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

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.

 User Friendliness (mudah digunakan)
Adequacy (kecukupan)

Learnability (mudah dipelajari)

Robustness (antisipasi kesalahan)

 Maintenatibility (mudah dirawat)

SOFTWARE QUALITY ATTRIBUTE (2)

 Maintenatibility (mudah dirawat)

Readability (mudah dibaca)

Extensibility (mudah diperluas)

Testability (mudah untuk diuji/ditelusuri)

Efficiency (efisiensi)

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

 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)

 Hak kekayaan intelektual (HaKI)

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

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

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)

Penggunaan CASE tools:

Graphical Editors

Digunakan untuk membuat model sistem

Data Dictionaries

Digunakan untuk mengatur unit-unit proyek

GUI Builders

Digunakan untuk mengkonstruksi antarmuka pemakai

Debugger

CASE TOOLS (2)

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

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

Pemodelan Sistem/ Informasi Requirement Definitions System and software design software design Implementation and unit testing

Integr ation and system testing

Operation and maintenance

 Requirements Analysis And Definition Pembentukan kebutuhan

 System And Software Design

Mengubah kebutuhan-kebutuhan menjadi bentuk karakteristik yang dimerngerti perangkat lunak

WATERFALL MODEL (2)

 Implementation And Unit Testing Penulisan program

 Integration And System Testing

Memeriksa program, mencari kesalahan

 Operation And Maintenance

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.

mengemukakan semua kebutuhannya. 3. Customer harus sabar.

4. Developer sering menunda pekerjaan. Anggota tim harus menunggu anggota lainnya

PROTOTYPE MODEL

Mendengarkan Pelanggan Membangun Konstruksi (prototipe) Uji Pelanggan (evaluasi)

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.

PROTOTYPE MODEL (2)

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

Penjelasan :

1. Kombinasikan elemet-element dari waterfall dengan sifat iterasi/perulangan.

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

EVOLUTIONARY MODEL

INCREMENTAL (2)

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.

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.

EVOLUTIONARY MODEL

INCREMENTAL (3)

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.

Kekurangan Incremental Model:

Hanya cocok untuk proyek berukuran kecil (tidak lebih dari 200.000 baris coding)

Mungkin terjadi kesulitan untuk memetakan kebutuhan pengguna ke dalam rencana spesifikasi masing-masing hasil increment

EVOLUTIONARY MODEL

INCREMENTAL (4)

Penjelasan :

 Customer Comunication

Membangun komunikasi yang baik dengan pelanggan

 Planning

Mendefinisikan sumber, batas waktu, informasi-informasi lain seputar proyek

 Risk Analyst

EVOLUTIONARY MODEL SPIRAL (2)

Identifikasi resiko management dan teknis

 Engineering

Pembangunan contoh-contoh aplikasi misalnya prototype

 Construction and release

Pembangunan, test, install dan report

 Customer Evaluation

Mendapatkan feedback dari pengguna berdasarkan evaluasi pada fase engineering dan fase instalasi

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

EVOLUTIONARY MODEL SPIRAL (3)

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

 Software Re-engineering (lanjutan)
Mengapa?

 Mengurangi resiko

SW yang baru dibangun membawa resiko yg tinggi

 Mengurangi biaya

REUSE BASED (2)

 Mengurangi biaya

Biaya untuk re-engineering sering lebih kecil dibanding membangun SW baru.

B. Reverse Engineering

Analisis SW kembali dalam tahap pemahaman dlm desain dan

spesifikasinya

Bisa sebagian proses re-engineering atau sebagian spesifikasi

sistem untuk diimplementasi ulang

Membangun database dan bangkitkan program informasi dari

proses ini

REUSE BASED (3)

proses ini

Mengapa?

 Kode aslinya telah dalam keterbatasan dimana sudah 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
Resiko yang dapat ditimbulkan
Sumber-sumber yang diperlukan
Tugas yang harus dilaksanakan
Patokan yang harus diikuti}

_{Usaha atau biaya yang dikeluarkan
Dan Penjadwalan}

Untuk mengestimasi biaya, pembagian tugas, dan penjadwalan, sebelum sebuah proyek direncanakan :

Langkah Awal dalam

Manajemen Perangkat Lunak

_{Memastikan tujuan dan ruang lingkup} _{Memperhatikan alternatif-alternatif solusi} _{Identifikasi batasan teknik dan manajerial}

Fokus Manajemen Proyek

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

Elemen terpenting dalam keberhasilan suatu proyek 2. Product

Perangkat lunak yang dihasilkan 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)}

 _{Bidang aplikasi (Application Domain)}

 _{Implementasi Teknologi (Technology Can Be}

Implemented)

 _{Batasan-batasan sistem (System Constrains)}  _{Kebutuhan pengguna (User Requirements)}

Permasalahan Dalam Manajemen Proyek

_{Bagaimana kualitas produk yang akan dihasilkan
Perkiraan / beban resiko yang timbul}

_{Ukuran perangkat lunak
Estimasi / perkiraaan dana
Estimasi / perkiraaan dana
Penjadwalan proyek}

_{Komunikasi dengan pelanggan
Tim perancang}

_{Sumber daya lainnya}

Fokus Dalam RPL

_{Analisa Resiko
Estimasi Biaya
Penjadwalan}

_{Manajemen proyek}

_{Pengecekan Kualitas hasil terkait dengan kualitas yang}

diinginkan bersama

Pengukuran dan satuan ukuran akan membantu untuk mengerti proses-proses dalam pengembangan dan produk itu sendiri. Proses dan produk diukur usaha

Pengukuran Perangkat Lunak

produk itu sendiri. Proses dan produk diukur usaha untuk meningkatkan kualitasnya.

1. Pengukuran Langsung

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

Pengukuran Perangkat Lunak (2)

dan cacat pada produk, yang dilaporkan pada sejumlah periode waktu

2. Pengukuran tidak Langsung

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

Mengapa perangkat Lunak Harus Diukur??

1. Untuk mengetahui karakteristik Perangkat Lunak

2. Proses evaluasi Perangkat Lunak

3. Prediksi kebutuhan Perangkat Lunak

Pengukuran Perangkat Lunak (3)

3. Prediksi kebutuhan Perangkat Lunak

4. Pengembangan Perangkat Lunak

Kualitas Pengukuran Perangkat Lunak :

_Correctness

Sesuai dengan spesifikasi yang diinginkan

_Maintability

Pengukuran Perangkat Lunak (4)

Kemudahan pemeliharaan dan stabil

_Integrity

Daya tahan terhadap serangan dari luar sistem

_Usability

Estimasi

Dalam aktifitas utama proyek yaitu perencanaan, dilakukan:

 _{Sumber daya manusia (ukuran orang/bulan)}

 _{Jangka waktu kronologis (Ukuran waktu kalender)}  _{Jangka waktu kronologis (Ukuran waktu kalender)}  _{Biaya (Ukuran uang Rp)}

Estimasi (2)

A. Tujuan Perencanaan Anggaran Proyek

 _{Untuk menjalankan apa yang telah ditentukan dalam}

tahap planning

 _{Memberikan arah/dukungan financial untuk membiayai}

proyek

 _{Untuk mengontrol dan mendokumentasikan}  _{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) (tambahan)

 _{Biaya selalu berhubungan dengan aktifitas}  _{Aktifitas selalu menggunakan sumber daya}

_{Analisis resiko merupakan serangkaian langkah untuk}

menyiasati resiko

_{Analisis resiko sangat penting dalam manajemen}

Analisis Resiko

proyek perangkat lunak. Beberapa hal yang harus diperhatikan berkaitan dengan resiko adalah: Masa yang akan datang, Perubahan, Pilihan.

_{Identifikasi resiko}

Melihat semua resiko sesuai dengan kategori(secara makro).

_{Perkiraan resiko}

Memperhitungkan lebih lanjut estimasi 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}

Pengendalian Resiko

Strategi Penanganan Resiko

1. Manajemen Resiko Reaktif

 _{Tim proyek beraksi pada resiko}  _mereka

menjumpainya

 _Pelonggaran  _{rencana penambahan resource}

antisipasi, misalnya kebakaran 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

2. Manajemen Resiko Proaktif

 _{Kinerja analisis resiko secara formal}

 _{Koreksi terorganisasi pada penyebab resiko}

 _{Pengujian sumber resiko yang diantaranya adalah}

perangkat lunak

Pengendalian Resiko (2)

perangkat lunak

 _{Pengembangan kemampuan untuk mengatur}

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}  _{Memerlukan dokumen kebutuhan yang akan digunakan}

untuk pengambilan keputusan menerima proyek/menolaknya. Jika menerima maka langkah selanjutnya adalah membuat proposal

Segitiga proyek (Proyek Triangle)

1. Time



_Penjadwalan

_tugas,

_penentuan

_durasi,

ketergantungan tugas

Perencanaan Proyek (2)

2. Money



_{Anggaran Belanja, sumber daya}

3. Scope

_{Strategi Perencanaan}  _{memilih dan menerapkannya}  _{Hasil tujuan}

 _{Asumsi/anggapan}  _Pembatasan

 _{Area/cakupan berhubungan dengan tugas dan}

pengiriman

Perencanaan Proyek (3)

pengiriman

_{Tahapan perencaan Proyek}

 _{Penentuan area/cakupan proyek}

 _{Pendefinisian tugas-tugas, teknik/tools (WBS, project}

Network Diagram)

 _{Pendefinisian sumber daya}

 _Penjadwalan  _{teknik/tools : PERT, CPM, Gantt Chart}  _{Penentuan Anggaran}

Tools dan Teknik Manajemen Proyek
Work Breakdown Structure

Project Network Diagram
Critical Path Method (CPM)

Perencanaan Proyek (4)

Program Evaluation and Review Technique (PERT)
Gantt Chart

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

4.

Tentukan pekerja dan sumber-sumber lainnya

5.

Buat jaringan tugas

Penelusuran

dan

pengendalian

dilakukan

setelah ada penjadwalan yang pasti, yaitu

memeriksa apakah tugas telah dilaksanakan

Penelusuran dan Pengendalian

memeriksa apakah tugas telah dilaksanakan

sesuai dengan jadwal.



_{Indikasi kualitas produk}



_Perkiraan

_{produktivitas}

_orang-orang

_yang

menghasilkan produk



_{Perkiraan manfaat dari penerapan metode dan}

tools

Tujuan Pengukuran Perangkat Lunak

tools



_{Membentuk dasar dari estimasi}



_{Menegaskan (Justify) permintaan tools baru dan}

 _{Kualitas perangkat lunak dihitung pada saat proses}

rekayasa perangkat lunak ataupun setelah diserahkan kepada pemakai.

 _{Satuan ukuran kualitas perangkat lunak pada saat}

proses rekayasa :

Ukuran Kualitas Perangkat Lunak

proses rekayasa :

1. Kompleksitas program 2. Modularitas yang efektif 3. Besarnya program

Penyebab Kegagalan (PL)

Penyebab kegagalan sebuah proyek PL :

 _{Batas waktu pengerjaan proyek yang tidak realistis}  _{Perubahan keinginan pelanggan}

 _{Meremehkan pekerjaan}

 _{Munculnya resiko yang dapat diperkirakan dan resiko}  _{Munculnya resiko yang dapat diperkirakan dan resiko}

yang diluar perkiraan

 _{Kesulitan secara teknis}

 _{Kesalahpahaman antara anggota tim proyek}  _{Kesalahan dalam manajemen proyek}

Komponen Dalam Proyek PL

 _{Manager Senior}

Menentukan isu-isu bisnis yang memiliki 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

 _Pelanggan

Menentukan jenis kebutuhan akan perangkat lunak yang akan direkayasa

 _{Pemakai Akhir (end-user)}

Komponen Dalam Proyek PL (2)

 _{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 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

5. Kualitas yang diperlukan serta keandalan sistem yang dibangun

6. Kepastian tanggal penyampaian ke pelanggan

7. Memiliki kemampuan sosialisasi (komunikasi) yang

Komponen Dalam Proyek PL (4)

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

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

2. Dekomposisi masalah

Menetapkan pembagian fungsi / aktivitas kerja pada 2 area utama, yaitu ;

 _{Fungsionalitas yang harus disampaikan}

 _{Proses yang akan dipakai untuk menyampaikannya}

Definisi Masalah dalam RPL (2)

ARTIFACT UML

Actor A Use Case 1 Use Case 2 Actor B 9: sortByName ( ) GrpFile read( ) open( ) create( ) fillFile( ) rep Repository name : char * = 0 readDoc( ) readFile( ) (from Persistence) FileMgr fetchDoc( ) sortByName( ) DocumentList add( ) delete( ) Document name : int docid : int numField : int get( ) open( ) close( ) read( ) sortFileList( ) create( ) fillDocument( ) fList 1 FileList add( ) delete( ) 1 File read( )

read() fill the code..

UI

MFC RogueWave DocumentApp

Persistence Window95 Windows95 Windows95 ºÐ»ê ȯ °æÀÇ Çϵå¿þ¾î¹× ³×Æ®¿÷À¸·ÎÀÇ Á¤º¸ ½Ã½ºÅÛ ¿¬° á ¸ðµ¨ - À©µµ¿ì 95 : Ŭ¶óÀ̾ðÆ® - À©µµ¿ì NT: ÀÀ¿ë¼-¹ö - À¯ ´Ð½º ¸Ó½Å: ÀÀ¿ë ¼-¹ö ¹× µ¥ÀÌŸ ¼-¹ö, Åë½Å ¼-¹ö - IBM ¸ÞÀÎÇÁ·¹ÀÓ: µ¥ÀÌŸ ¼-¹ö, Åë½Å ¼-¹ö Repository DocumentList Customer name addr withdraw() fetch() send() receive() <<entity>> Domain Expert Openning Writing Reading Closing

add file [ numberOffile==MAX ] / flag OFF add file close file close file Use Case 3 Use-Case

Diagram Class Diagram State Diagram

Deployment Diagram Class user : »ç¿ëÀÚ mainWnd : MainWnd fileMgr : FileMgr

repository : Repository document : Document gFile : GrpFile

L

1: Doc view request ( ) 2: fetchDoc( ) 5: readDoc ( ) 7: readFile ( ) 3: create ( ) 6: fillDocument ( ) 4: create ( ) 8: fillFile ( ) global ¹®¼-°ü¸® Ŭ¶óÀ̾ðÆ®.EXE Windows NT ¹®¼-°ü¸® ¿£Áø.EXE WindowsNT Solaris ÀÀ¿ë¼-¹ö.EXE AlphaUNIX IBM Mainframe µ¥ÀÌŸº£À̽º¼-¹ö ¹®¼-°ü¸® ¾ÖÇø´ Document FileManager GraphicFile File FileList user mainWnd fileMgr :

FileMgr document : Document gFilerepository

1: Doc view request ( ) 2: fetchDoc( ) 3: create ( ) 4: create ( ) 5: readDoc ( ) 6: fillDocument ( ) 7: readFile ( ) 8: fillFile ( ) 9: sortByName ( ) Ư Á¤¹®¼-¿¡ ´ëÇÑ º¸±â¸¦ »ç¿ëÀÚ°¡ ¿äûÇÑ´Ù. È-ÀÏ°ü¸®ÀÚ´Â Àоî¿Â ¹®¼-ÀÇ Á¤º¸¸¦ ÇØ´ç ¹®¼- °´Ã¼¿¡ ¼³Á¤À» ¿äûÇÑ´Ù. È-¸é °´Ã¼´Â ÀоîµéÀÎ °´Ã¼µé¿¡ ´ëÇØ À̸§º°·Î Á¤·ÄÀ» ½ÃÄÑ È-¸é¿¡ º¸¿©ÁØ´Ù.

Forward Engineering(Code Generation) and

Reverse Engineering

Executable System User Interface

Definition

Source Code edit, compile, debug, link Collaboration Diagram Sequence Diagram Component Diagram Package Diagram

DIAGRAM-DIAGRAM DI UML

Use Case DiagramsUse Case

DiagramsUse Case Diagrams State DiagramsState DiagramsObject Diagrams Use Case

DiagramsUse Case DiagramsActivity Diagrams State DiagramsState DiagramsClass Diagrams Deployment Diagram Scenario DiagramsScenario DiagramsSequence Diagrams State DiagramsState DiagramsState Diagrams Component DiagramsComponent Diagrams Component Diagrams Model Scenario DiagramsScenario Diagrams Collaboration 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 • 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 • 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 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

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

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

posisi sebuah jabatan

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

• 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

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

•

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

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

• <<include>> termasuk didalam use case lain (required) / (diharuskan)

– Pemanggilan use case oleh use case lain, contohnya adalah pemanggilan sebuah fungsi program

– Tanda panah terbuka harus terarah ke sub use case – Gambarkan association include secara horizontal – Gambarkan association include secara horizontal

Register for courses

<<include>>

Logon validation <<include>>

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

Association antara use case (Lanjut)

Buka Rekening <<extend>> Buka Deposito Nasabah

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

• 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

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.

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

pada paket yang sama

Nama Class Atribut

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

MULTIPLICITY

1..* 0..* 1 *

• Unspecified

• Exactly one

• Zero or more (many, unlimited)

• One or more

2..4 0..1 1..*

• One or more

• Zero or one (optional scalar role)

• Specified range

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

pelanggan_reg no int(5) nomor_pelanggan varchar(12) nama_lengkap varchar(20) username varchar(13) password varchar(13) email varchar(30) cari() simpan() batal() i_01 nomor_agenda int(5) tgl_agenda varchar(15) nomor_pelanggan varchar(12) nama pelanggan varchar(20) alamat_pelanggan varchar (30) no_ktp varchar(19) no_telpon varchar(13) tarif_lama varchar(2) daya_lama varchar(6) tarif_baru varchar(2) daya_baru varchar(6) peruntukan varchar(20) gardu varchar(20) status varchar(1) simpan() batal() 1 1 1 1 user id_user varchar(50) password varchar(50) nama_lengkap varchar(100) email varchar(100) bagian varchar(100) referensi varchar(100) level varchar(50) 1 n 1 n master_tarif nomor int(5) peruntukan varchar(10) tarif varchar(2) daya varchar(10) bp int(10) ujl int(10) materai int(10) kwitansi nomor_kwitansi int(5) tgl_kwitansi varchar(15) nomor_agenda int(5) nomor_pelanggan varchar(12) bp int(10) ujl int(10) materai int(10) total int(10) status int(1) userid varchar(10) simpan() batal() tambahkwitansi() cari() n 1 n 1 n n n n perintah_kerja nomor_pk int(5) tgl_pk varhcar(15) no_kwitansi int(5) 1 1 1 1 keluhan_pelanggan id int(5) nomor_pelanggan varchar(12) nama_pelanggan varchar(20) email varchar(100) keluhan text kode_security varchar(6)

Contoh Kasus (Acknowledgments Toeko triyanto)

no_kwitansi int(5) tgl_kwitansi varchar(15) status int(1) cari() mutasi nomor_mutasi int(5) tgl_mutasi varchar(15) nomor_pk int(5) tgl_pk varchar(15) status int(1) cari() 1 1 1 1 master_status nomor_status int(1) keterangan varchar(15) 1 1 1 1 kode_security varchar(6) simpan() batal() tunggakan nomor_pelanggan varchar(20) tanggal_rekening varchar(15) rupiah_ptl int(15) tagihan_lain_lain int(15) ppn int(12) ppj int(15) materai int(7) total_tagihan int(15) tanggal_bayar varchar(15) modul id_modul int(5) nama_modul varchar(50) link varchar(100) static_content text gambar varchar(100) publish enum('Y','N') status enum('user','admin','umum') aktif enum('Y','N') urutan int(5) simpan() batal() master_pelanggan nomor_pelanggan varchar(12) nama_pelanggan varchar(20) penunjukan_alamat varchar (2) alamat_pelanggan varchar(18) nomor_bangunan varchar(3) nomor_rt int(3) nomor_rw int(2) golongan_tarif varchar(3) daya int(6) nomor_meter varchar(6) nomor_ktp varchar(20) telpon varchar(13) gardu varchar(20) 1 1 1 1 n 1 n 1 n 1 n 1 n n n n

Statechart

Statechart

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

Notasi State menggambarkan kondisi _{sebuahentitas, dan digambarkan dengan}

segiempat yang pinggirnya tumpul

dengan nama state didalamnya

State1

Transition

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

.

Transition

sebuah kondisi awal sebuah

State1

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.

• 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

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

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,

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

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

• Submachine State

– Sejenis composite state

State 2 State 1 State 3 • Composite State – Kumpulan dari beberapa states yang setidaknya dalam sebuah region – Orthogonal State, jenis composite state lebih dari 1 region

– Digunakan untuk mendukung konsep encapsulation

– Sebuah state tidak boleh mempunyai region dan submachine secara bersamaan

– Nama state mempunyai sintaks :

nama submachine state : referenced state machine – Sejenis composite state

yang isinya didefinisikan oleh state machine lain – State Machine yang berisi

submachine state disebut “Containing state machine” – Sebuah state yang

dihubungkan ke state machine lainnya

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