Dyah Puspito Dewi Widowati

dyah013@kominfo.go.id

• 2006 – 2010 S1 Teknik Informatika Universitas Islam Sultan Agung

• 2011 – 2013 S2 Magister Sistem Informasi Universitas Diponegoro

• 2011 – 2013 IT Staff di Universitas Islam Sultan Agung

• 2013 – 2015 Dosen di Teknik Informatika Universitas Islam Sultan Agung
• 2015 – Sekarang Instruktur di BPPTIK Kementerian Kominfo
• 2016 – Sekarang Asesor Kompetensi
• 2019 – Sekarang Direktur LSP BPPTIK
SISTEM ANALISIS DAN
DESAIN
Oleh:
Dyah Puspito Dewi Widowati, S.T., M.Kom.
Apa dan Mengapa Systems Analysis and Design?
Kegagalan Project Software
• Dibatalkan sebelum selesai
• Selesai tapi tidak pernah dipakai
• Tidak bermanfaat bagi pengguna
• Tidak sesuai dengan keinginan pengguna
6
Tantangan Pengembangan Software

7
Software Berkualitas?
• Komputer Datang untuk Efisiensi!

Sesuai Kebutuhan

Ada Keuntungan
Software Sistem Kita Berkualitas?
Software Development Evolution
• How to Write a Code
(Coder or Programmer)
• How to Develop a Software
(Software Engineer)
• How to Manage Software
(Enterprise Architect)
Software Berkembang, Semakin Banyak dan
Tumbuh Besar!
Bagaimana cara
mengelola semua software?

Apakah sudah selaras antara Apa yang harus dilakukan

proses bisnis bila ada penambahan
dan software yang dibangun? fitur baru?

Pimpinan ingin melihat

helicopter view dari
semua software yang ada?
Pembangunan Sistem Informasi
1.1 Sistem dan Sistem Informasi
1.2 Siklus Hidup Pengembangan Sistem Informasi
1.1 Sistem dan Sistem Informasi
• Sistem informasi merupakan pendukung utama proses bisnis dalam
organisasi dan mencerminkan keunggulan suatu organisasi.
• Informasi merupakan aset penting.
• Tahapan pengelolaan informasi:
a. Collect
b. Process
c. Store
d. Disseminate
Konsep Sistem Informasi
Sifat-sifat SI yang baik:
Feedback
1. Pengelolaan
informasi yang
efektif.
2. Manajemen
Input Processing Output informasi harus
efektif.
3. Luwes.
Komponen-komponen SI

Actors
Instructions
Bridge

Five-Component Framework

Hardware Software Data Procedures People

Computer Side Human Side

1.2 Siklus Hidup Pengembangan
Sistem Informasi
Siklus Hidup Pengembangan SI

• Dalam Bahasa Inggris: System Development Life Cycle (SDLC)

• Konsep SDLC: urutan-urutan fase, aktivitas dan keluaran setiap fase
terkait dengan pengembangan SI. Setiap fase menggunakan hasil dari
fase sebelumnya.
• Model SDLC:
a. Waterfall
b. V Model
Requirements
definition

System and software

design
Waterfall Model
Implementation
and unit testing

Integration and
system testing

Operation and
maintenance
 V Model
Tahapan Verifikasi Tahapan Validasi

Tahapan validasi merupakan

Tahapan verifikasi mengacu serangkaian tahapan yang
kepada usaha penyesuaian mengacu kepada kesesuaian
spesifikasi software dengan software dengan spesifikasi
kebutuhan klien. yang sudah ditetapkan.
Analisis dan Perancangan Sistem
2.1 Pengembangan Sistem Informasi
2.2 Tantangan Pengembangan Sistem Informasi
2.3 Proyek Pengembangan Sistem Informasi
2.1 Pengembangan Sistem
Informasi
Asal mula pengembangan system adalah karena ada system request.
System request:
1. Enhancement
2. Correction
3. Replacement
4. Anticipate and adaptive

6 alasan dibuat system request:

a. Mengurangi biaya
b. Meningkatkan layanan
c. Meningkatkan kinerja
d. Mendukung produk dan layanan baru
e. Tambahan informasi
f. Menguatkan proses kendali
• Pembangunan SI dipengaruhi oleh faktor internal dan eksternal.
• Faktor internal:
1. Strategic plan Strategic
plan
2. Top manager Top
managers
Technology
3. User requests
4. Information technology department User
Suppliers
5. Existing system and data requests

• Faktor eksternal:
1. Technology Information Internal External
technology Customers
2. Supplier department

3. Customer
Existing
4. Competitor systems and Competitors
5. Economy data
The
6. Government Government
economy
2.2 Tantangan Pengembangan
Sistem Informasi
Tantangan Pengembangan SI
• Ubiquitous computing
Software harus dapat berjalan pada mesin apa saja
• Netsourcing
Aplikasi yang sederhana dan canggih
• Open source
Mendistribusikan kode program sehingga dapat dimodifikasi oleh konsumen
• New economy
Memfasilitasi komunikasi massa dan sistribusi produk secara massal
Penyebab Kegagalan Pengembangan SI
• Perencanaan yang tidak realistis, terlalu banyak kasus
• Penelusuran yang tidak efektif
• Terlalu terpaku pada kebutuhan sementara
• Tidak memperhitungkan resiko
2.3 Proyek Pengembangan Sistem
Informasi
SI yang baik memiliki atribut sbb:
a. Maintainability
Dapat berevolusi memenuhi perubahan kebutuhan.
b. Dependability
Dapat dipercaya / diandalkan
c. Efficiency
Dapat dioperasikan dengan menggunakan sumber daya system
secara efisien
d. Acceptability
Dapat diterima oleh user (mudah dipahami, compatible dengan
sistem lain)
Tim Pengembangan Sistem Informasi
Organisasi tim
1. Project manager
2. Software engineer
• Analyst
• Designer
• Programmer
3. System configuration management
4. System administrator
5. Software quality
• Software test engineer
• Software quality assurance
Tanggung Jawab Profesional
• Confidentiality
Kerahasiaan data klien
• Competence
Tidak mengerjakan sesuatu di luar kompetensinya
• Intelectual property rights
Memperhatikan HAKI (patent, copyrights, dll)
• Computer misuse
Tidak menyalahgunakan keahliannya dengan menggunakan computer klien di
luar pekerjaannya, seperti bermain game atau menyebarkan virus.
Pengumpulan Data dan Informasi
3.1 Konsep Dasar Informasi
3.2 Karakteristik Kualitas Informasi
3.3 Kategori Informasi
3.4 Teknik Pengumpulan Informasi
3.1 Konsep Dasar Informasi
Sistem Informasi: mengolah data menjadi informasi
a. Data: kumpulan fakta
b. Informasi: kumpulan fakta yang telah disusun, memiliki nilai tambah
c. Pengetahuan: pemahaman atas sekumpulan informasi untuk
mendukung keputusan
3.2 Karakteristik Kualitas
Informasi
Accessible Accurate Complete Flexible

Relevant Reliable Secure Simple

Timely Verifiable
3.3 Kategori Informasi
Bentuk Informasi untuk Pengguna

Instruction Command Advisory

Answer Historical Predictive

3.4 Teknik Pengumpulan
Informasi
Wawancara Kuesioner Sampling

Investigasi Observasi
Sistem Analisis dan Desain dengan UML
4.1 Pengertian UML
4.2 Use Case Diagram
4.3 Activity Diagram
4.4 Class Diagram
4.5 Sequence Diagram
4.6 Bring It All Together
4.1 Pengertian UML
Pengertian
• UML: bahasa pemodelan standar
• UML memiliki sintaks dan semantik, dalam arti ada aturan-aturan
yang harus diikuti. Bagaimana elemen-elemen yang kita buat
berhubungan satu dengan lainnya harus mengikuti standar yang ada.
• UML bukan hanya sekedar diagram, tetapi juga menceritakan
konteksnya
Pengaplikasian UML
• Merancang perangkat lunak
• Sarana komunikasi antara perangkat lunak dengan proses bisnis
• Menjabarkan sistem secara rinci untuk analisa dan mencari apa yang
diperlukan sistem.
• Mendokumentasi sistem yang ada, proses-proses yang ada dan
dokumentasinya.
Diagram-diagram UML
• Diagram use case (use case diagram)
• Diagram kelas (class diagram)
• Diagram paket (package diagram)
• Diagram komponen (component diagram)
• Diagram deployment (deployment diagram)
• Diagram statechart (statechart diagram)
• Diagram aktivitas (activity diagram)
• Diagram interaksi dan sequence (interaction and sequence diagram)
• Diagram komunikasi (communication diagram)
4.2 Use Case Diagram
Use Case Diagram
• Menggambarkan fungsionalitas yang diharapkan dari sebuah sistem. Yang
ditekankan adalah “apa” yang diperbuat sistem.
• Menggambarkan kebutuhan sistem dari sudut pandang user.
• Mengfokuskan pada proses komputerisasi (automated processes).
• Menggambarkan hubungan antara use case dan actor.
• Use case menggambarkan proses sistem (kebutuhan sistem dari sudut pandang
user)
• Secara umum use case adalah:
• Pola perilaku sistem
• Urutan transaksi yang berhubungan yang dilakukan oleh satu actor
• Use case diagram terdiri dari
• Use case
• Actors
• Relationship
• System boundary boxes (optional)
• Packages (optional)
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
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
• Tidak boleh ada komunikasi langsung antar actor
• 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 sistem
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
<<include>>
catat
Buka <<include>>
data Register for courses
Rekening
pribadi
<<include>>
Logon validation

Nasabah

Maintain curriculum
Association antara use case (Lanjut)

<<extend>> perluasan dari use case lain jika kondisi atau syarat terpenuhi
• Kurangi penggunaan association Extend ini, terlalu banyak pemakaian
association ini membuat diagram sulit dipahami.
• Tanda panah terbuka harus terarah ke parent/base use case
• Gambarkan association extend secara vertical

Buka
Rekening

<<extend>>

Nasabah
Buka
Deposito
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
Usecase berdasarkan sistem usulan atau berdasar program
Contoh Kasus Penggajian

Use Case Absen

Cetak Rekap Absen

TU

>
Administrasi

e>
udl
Inc
<<
Input Data Absen Harian

Deskripsi use case Absen

Nama : Use Case Diagram Absen
Actor : TU dan Administrasi
Deskripsi : TU mencetak Rekap Absen kemudian diserahkan kepada Administrasi
Nama Use Case : <<Include>> input data absen harian
 Use Case Rekap Biodata Pegawai

Cetak Rekap Biodata

Pegawai

TU Administrasi

>>
ude
l
Inc
<<
Input Data Pegawai,
Pendidikan, Keluarga

Deskripsi Use Case Rekap Biodata Pegawai

Nama : Use Case Rekap Biodata Pegawai
Actor : TU dan Administrasi
Deskripsi : TU mencetak Rekap Biodata Pegawai kemudian diserahkan kepada Administrasi
Nama Use Case : <<Include>> input data pegawai, Pendidikan dan Keluarga.
 Use Case Pengolahan Daftar Data Pegawai dan Gaji (DDPG)

Input Data Pegawai,data

pendidikan, data keluarga
PKS, Insentif, Fungsional,
Transport, Potongan
>>
lu de
Inc
<<

Cetak Slip Gaji

Administrasi Pegawai

>
e>
lud
Inc
<<
Input Total Absensi Pegawai

Deskripsi Use Case Pengolahan Data Pegawai dan gaji (DDPG)

Nama : Use Case Pengolahan Data Pegawai dan Gaji
Actor : Administrasi dan Pegawai
Deskripsi : Administrasi Mencetak Slip Gaji kemudian diserahkan kepada Pegawai
Nama Use Case : <<Include>> Input total absensi pegawai dan input data pegawai, data pendidikan,
data keluarga, PKS, insentif, fungsional, transport dan potongan.
4.3 Activity Diagram
• Menggambarkan proses bisnis dan urutan aktivitas dalam sebuah proses
• Dipakai pada business modeling untuk memperlihatkan urutan aktifitas proses
bisnis
• Struktur diagram ini mirip flowchart atau Data Flow Diagram pada perancangan
terstruktur
• Sangat bermanfaat apabila kita membuat diagram ini terlebih dahulu dalam
memodelkan sebuah proses untuk membantu memahami proses secara
keseluruhan
• Activity diagram dibuat berdasarkan sebuah atau beberapa use case pada use
case diagram
Simbol Activity Diagram
Simbol Keterangan
Start Point

End Point

Activities

Fork (Percabangan)

Join (Penggabungan)

Decision

Sebuah cara untuk mengelompokkan

Swimlane activity berdasarkan Actor
(mengelompokkan activity dalam
sebuah urutan yang sama)
Activity
• Activity menggambarkan sebuah pekerjaan/tugas dalam workflow.
• Pada UML, activity digambarkan dengan simbol belah ketupat=‘lozenge’
(horizontal top and bottom with convex sides).

Activity
Start State

• Start state menunjukkan dimulainya suatu workflow pada sebuah activity

diagram.
• Hanya ada satu start state dalam sebuah workflow.
• Pada UML, start state digambarkan dengan simbol lingkaran yang solid.

Start State
End State
• End state menggambarkan akhir atau terminal dari pada sebuah activity diagram.
• Bisa terdapat lebih dari satu end state pada sebuah activity diagram.
• Pada UML, end state digambarkan dengan simbol sebuah bull’s eye.

End State
State Transitions

• State transition menunjukkan kegiatan apa berikutnya setelah suatu

kegiatan sebelumnya.
• Pada UML, state transition digambarkan oleh sebuah solid line
dengan panah.

State Transition
Decisions
• Decision adalah suatu titik/point pada activity diagram yang mengindikasikan
suatu kondisi dimana ada kemungkinan perbedaan transisi.
• Pada UML, decision digambarkan dengan sebuah simbol diamond.

Decision
Swimlanes
• Object swimlane untuk menggambarkan objek mana yang bertanggung jawab
untuk aktivitas tertentu.
 CONTOH
ACTIVITY
DIAGRAM

Penarikan
Uang dari
Account Bank
Melalui ATM
Petunjuk Membuat Diagram Aktivitas

• Mulailah dengan node awal untuk titik awal.

• Tambahkan partisi jika relevan untuk analisis yang dibuat.
• Tambahkan aksi untuk setiap langkah utama dari use case.
• Tambahkan alur dari setiap aksi ke aksi lain, keputusan atau node akhir. Setiap
aksi hanya mendapat satu alur masuk dan satu alur keluar menuju ke forks, joins,
decisions, dan merges.
• Tambahkan decisions jika alur dipecah menjadi beberapa pilihan. Jangan lupa
untuk menggabungkan kembali dengan merge.
• Tambahkan forks dan joins jika aktivitas akan dilakukan secara paralel.
• Akhiri proses dengan notasi untuk akhir aktivitas.
4.4 Class Diagram
Pengertian
• Diagram kelas: Diagram yang digunakan untuk menampilkan
beberapa kelas serta paket-paket yang ada dalam sistem / perangkat
lunak yang sedang kita kembangkan.
• Diagram kelas (Class Diagram) memberi kita gambaran (diagram statis
) tentang sistem / perangkat lunak dan relasi-relasi yang ada di
dalamnya.
Kelas (class) dan Objek
• Kelas: satu set objek yang memiliki atribut dan perilau yang sama.
• Kelas adalah sejenis alat pengklasifikasi. Ex: volkswagen, toyota dan
ford merupakan kumpulan mobil, sehingga nama kelasnya mobil.
• Objek: entitas yang bersifat unik yang mengikuti aturan-aturan yang
sudah didefinisikan dalam kelasnya.
Notasi Kelas

Class Name • Kolom paling atas merupakan

representasi dari nama kelas
attributes • Kolom yang tengah berisi atribut-
atribut yang dimiliki kelas tersebut
• Kolom terakhir berisi operasi atau
operations
method
Attribute dan Operation/Method
• Attribute: merupakan properti dari sebuah kelas yang
melambangkan nilai-nilai yang mungkin ada pada kelas
tersebut.
• Operation/Method: merupakan behavior(tingkah laku) atau
fungsi yang dapat dilakukan oleh kelas tersebut.
CONTOH
Visibility
• Visibility: nilai yang diijinkan untuk dilihat atau di akses
• Untuk menentukan visibilitas anggota kelas (yaitu, atribut atau
method) terdapat notasi berikut yang harus ditempatkan sebelum
nama anggota kelas.
o (+) untuk public
o (-) untuk private
o (#) untuk protected
o (~) untuk package
Visibility (lanjut)
• Public : dapat dipakai oleh kelas apa saja.
• Private : tidak dapat di panggil dari luar kelas yang bersangkutan.
Hanya dapat di pakai dalam kelas yang bersangkutan
• Protected : hanya dapat di panggil oleh kelas yang bersangkutan dan
anak kelas yang diwarisinya.
• Package : menunjukkan atribut tersebut dapat dilihat oleh kelas lain
yang masih terdapat dalam paket yang sama.
Relasi Antar Kelas
• Associations
• Directed Association
• Aggregration
• Composition
• Generalization
• Dependency
• Realization
Associations
• Dapat diartikan sebagai relasi ".. has a..". Digambarkan sebagai garis
lurus antara dua kelas. Namun tidak berarti bahwa kelas satu
memiliki/dimiliki kelas yang lain, tetapi kelas lain dapat berelasi juga
dengan kelas yang sama.
Directed Association
• Relasi seperti asosiasi namun menggambarkan objek atau aliran
kejadian berasal dari salah satu kelas, sedang kelas yang lainnya
bersifat pasif.
Aggregration
• Agregasi mengimplikasikan kepemilikan suatu kelas (“...memiliki...”).
• Terdapat kelas sebagai part class (kelas bagian) yang merupakan
bagian dari kelas lain (whole class). Namun jika whole class tidak ada,
part class masih dapat berdiri sendiri.

Bag

Apples Milk
Composition
• Bisa disebut juga sebagai strong agregation, dapat diartikan “..is part
of..” (“..bagian dari..”). Seperti halnya relasi agregasi, namun apabila
whole class hilang, maka mustahil part class untuk ada.
Generalization
• Dapat diartikan sebagai relasi "..is a.." Digunakan untuk
merepresentasikan pewarisan. Suatu kelas (child class) dapat
diturunkan dari kelas lain dan mewarisi semua atribut dan method
induknya (parent class) dan dapat menambah method atau atribut
baru.
Dependency
• Hubungan antar-class di mana sebuah class memiliki ketergantungan
pada class lainnya tetapi tidak sebaliknya.
• Perubahan pada salah satu elemen kelas berdampak pada kelas lain
Realization
• Hubungan antar-class di mana sebuah class memiliki keharusan untuk
mengikuti aturan yang ditetapkan class lainnya. Biasanya realization
digunakan untuk menspesifikasikan hubungan antara sebuah
interface dengan class yang mengimplementasikan interface tersebut
.
Multiplisitas Relasi
• Multiplisitas adalah jumlah banyaknya obyek sebuah class yang
berelasi dengan sebuah obyek lain pada class lain yang berasosiasi
dengan class tersebut.

Multiplisitas Keterangan
* Banyak
0 Tepat nol
1 Tepat satu
0..* Nol tau lebih
1..* Satu atau lebih
0..1 Nol atau satu
Contoh Multiplisitas Relasi
CONTOH CLASS DIAGRAM
4.5 Sequence Diagram
• Menggambarkan interaksi antar objek di dalam dan di sekitar sistem

• Biasa digunakan untuk menggambarkan skenario atau rangkaian langkah-langkah yang

dilakukan sebagai respons dari sebuah event untuk menghasilkan output tertentu.

• Diawali dari apa yang men-trigger aktivitas tersebut, proses dan perubahan apa saja yang
terjadi secara internal dan output apa yang dihasilkan.
• Sequence diagram terdiri atas:
 Dimensi vertikal (waktu)
 Dimensi horizontal (objek-objek yang terkait).

• Masing-masing objek, termasuk aktor, memiliki lifeline vertikal.

• Berupa message yang digambarkan terhadap waktu.
• Message digambarkan sebagai garis berpanah dari satu objek ke objek lainnya.
• Pada fase desain berikutnya, message akan dipetakan menjadi operasi/metoda
dari class.

• Activation bar menunjukkan lamanya eksekusi sebuah proses, biasanya diawali

dengan diterimanya sebuah message.
• Untuk objek-objek yang memiliki sifat khusus, standar UML mendefinisikan icon
khusus untuk objek boundary, controller dan persistent entity.
Desain Use case

System ATM BCA

Account Penarikan uang

Holder
sukses
Actor_4
Transfer uang

Pembayaran
telpon
Boundary
Case scenario Untuk penarikan uang sukses

• Keyword : Format teks

1. Account Holder memasukkan kartu ATM
2. A.H memasukkan nomor pin
3. System mengecek nomor pin
4. System beri info kepada A.H untuk memasukkan
jumlah uang yg ditarik
5. A.H memasukkan jumlah uang
6. System mengecek jumlah uang
7. System mengeluarkan uang untuk A.H
8. ATM mencetak Bukti traansaksi
9. ATM mengeluarkan kartu ATM
Contoh Sequence Diagram
Proses pemesanan buku

Cart Catalog Authentication Order

Customer

Put in shopping cart

Verify availability

Return availability

Buy shopping cart

Verivy customer

Return Customer chek

Send order
4.6 Bring It All Together
Use Case
Activity
Class
Sequence