Pengembangan Perangkat

Lunak
Dr. Mohammad Iqbal

Universitas Gunadarma
Workshop Peranan Teknologi Informasi dan Komunikasi
dalam Pengembangan Aplikasi Cerdas
12 Juli 2018 di Lab E531 Kampus Kelapadua
USB (Unlimited Software Building) 2018
Outline
1. Pendahuluan : Pengertian, definisi, tujuan,
karakteristik produk perangkat lunak
2. Tahapan pengembangan perangkat lunak.
3. Teknik, model dan metode pengembangan
Perangkat Lunak.
4. Praktek pengembangan perangkat lunak
1. Pendahuluan
Pengertian Produk perangkat lunak
• Produk Perangkat Lunak menurut Ian Sommerville
didefinisikan sebagai berikut:
• Software Products are Software Systems delivered to a
customer with the documentation which describes how to
install and use the system
• Produk perangkat lunak adalah sistem perangkat lunak
beserta dokumentasinya yang menjelaskan prosedur
penyiapan dan penggunaan perangkat lunak tersebut.
1. Pendahuluan
Definisi produk perangkat lunak
a. instruksi-instruksi yang jika dieksekusi akan
memberikan layanan-layanan atau fungsi seperti
yang diinginkan
b. Struktur data yang diperlukan oleh suatu program
untuk memanipulasi informasi
c. Dokumen-dokumen yang mendeskripsikan
penggunaan suatu program.
Tujuan Rekayasa perangkat lunak
 Menghasilkan suatu produk perangkat lunak
1. Pendahuluan
Karakteristik produk perangkat lunak
1. Perangkat lunak adalah suatu produk yang lebih
menekankan pada kegiatan rekayasa (engineering)
bukan kegiatan manufacturing (rancang bangun di
pabrik) yang rumit.
2. Perangkat lunak bukanlah produk yang dapat usang
atau rusak untuk kemudian dibuang, seperti halnya
produk perangkat keras : Yang dapat terjadi adalah
produk-produk perangkat lunak tersebut tidak dapat
melayani beberapa kebutuhan yang dikehendaki
pemakainya, disebabkan berkembangnya kebutuhan-
kebutuhan baru, sehingga perlu dilakukan perubahan-
perubahan pada perangkat lunak tersebut
1. Pendahuluan
Karakteristik produk perangkat lunak
3. Kebanyakan perangkat lunak tidak dibangun dari
perangkat lunak-perangkat lunak yang sudah ada.
• Pembangunan aplikasi baru kebanyakan dimulai dari
awal, dari tahap analisis sampai tahap pengujian
• Kini ada paradigma baru mulai dikembangkan, yaitu
konsep reuseability
1. Pendahuluan
Karakteristik produk perangkat lunak (yang Baik)
1. Pendahuluan
Karakteristik produk perangkat lunak (yang Baik)
2. Tahapan pengembangan Software
• Pengembangan Software bukan sekedar
dengan cara coba-coba – Trial & Error

Input Output
Buat Kode
& Tes

Dilakukan
sampai pas
2. Tahapan pengembangan Software
• Pengembangan Software harus dengan
metode Pengembangan Produk
Teknologi : Aplikasi
pengetahuan ilmiah
dalam industri atau
bisnis
Tool : Implementasi
atau penggunaan
mesin untuk
Products menyelesaikan tugas
tertentu.
Metode : aturan
Metode Langkah untuk
menyelesaikan suatu
Software Engineering Project Management
proses.
2. Tahapan pengembangan Software
Manajemen Proyek Software akan mencegah resiko-
resiko yang mungkin terjadi dalam proses
pengembangan
Produk
P
r
o
d
u
c
t
s

Meth
ods
Pr
o
d
u
ct
s

Metods

Ide
2. Tahapan pengembangan Software
Perencanaan

Definisi
Konsep

Management
Plan
Risk Identifikasi
Databases
Analysis Kandidat
ROI
Specifications Arsitektur
Analysis
Needs
Project Assessment
Plans
Pemasaran &
System
Requirement

Analisa
2. Tahapan pengembangan Software :
Pendekatan Build and Fix

13
2. Tahapan pengembangan Software :
Build and Fix – Kelebihan dan Kekurangan
Kelebihan Kekurangan
Akan bekerja untuk Satu langkah ke depan
proyek yang kurang dari untuk membuat code
200 LOC (line of code) dan tes
Tidak bisa untuk proyek
S/W besar
Tidak ada spec S/W
Tidak ada model life
cycle

14
2. Tahapan pengembangan Software :
Basic 1074 Life Cycle
2. Tahapan pengembangan Software :
Full 1074 Life Cycle (1)
2. Tahapan pengembangan Software :
Full 1074 Life Cycle (2)
2. Tahapan pengembangan Software : Full
1074 Life Cycle – Kelebihan dan Kekurangan

Kelebihan Kekurangan
Poin awal untuk Terlalu banyak Proses
mendefiniskan life cycle
Mengandung banyak hal Mengandung terlalu
dari life cycle yang banyak hal yang kadang
dapat mendukung apa tidak dibutuhkan
yang kita butuhkan
Proses untuk Tidak semua life cycle
mendefinisikan life cycle dapat diimplementasikan
2. Tahapan pengembangan Software :
Waterfall Model

Planning

Analysis

Design

Build

Test

Deploy
2. Tahapan pengembangan Software : Waterfall
Model – Kelebihan dan Kekurangan

Kelebihan Kekurangan
Mudah dipahami Tidak membuat model
dunia nyata secara tepat
Mudah diukur Terlalu banyak
dokumentasi
Menerapkan disiplin
Penyebarannya
dikendalikan dengan
dokumen
2. Tahapan pengembangan Software :
Waterfall dengan Purwarupa / Prototipe
Process Steps Process Gates Prototypes

REQUIREMENTS DEFINITION PROTOTYPE

REVIEW 1

HIGH LEVEL DESIGN PROTOTYPE

REVIEW
2

DETAIL DESIGN PROTOTYPE

REVIEW
3

SYSTEM CONSTRUCTION
REVIEW

VERIFICATION & VALIDATION

REVIEW

SYSTEM DELIVERY POST

REVIEW IMPLEMENTATION
REVIEW

Project Management Support Processes

Risk Reduction Training Planning Configuration Management Estimating Metrics Quality Assurance
2. Tahapan pengembangan Software : Model
Prototipe – Kelebihan dan kekurangan

Kelebihan Kekurangan
Mudah dipahami Tidak berhenti menghasilkan
prototipe
Mudah diukur Prototipe akan membuka
kesempatan hacking
Modeling dunia nyata
Berulang di setiap langkah
proses
Penyebarannya dikendalikan
dengan dokumen
2. Tahapan pengembangan Software :
Model Spiral
2. Tahapan pengembangan Software :
Model Spiral – Kelebihan dan Kekurangan
Kelebihan Kekurangan
Mengurangi resiko Internal development
sistem yang sangat besar
Mendukung penggunaan Biaya yang cukup mahal
kembali
Jaringan Maintenance dan Membutuhkan organisasi
development yang luas yang sudah teritegrasi
Mudah melihat hasil Banyak menggunakan
dengan adanya prototipe tools terkait resiko dan
prototipe
Pengujian fokus ke Resiko
2. Tahapan pengembangan Software : Rapid
Application Development (RAD)
2. Tahapan pengembangan Software :
RAD – Kelebihan dan Kekurangan
Kelebihan Kekurangan
Interaksi user yang sangat Keterlibatan pengguna sangat
kompleks tinggi
Cepat mengimplementasikan Membutuhkan kematangan alat
konsep dan proses
Pembangunan secara bertahap Meningkatkan biaya overhead jika
dan teratur terlalu banyak prototipe
Pengendalian pengiriman yang
sangat ketat
Penentuan ekspektasi yang buruk
dikendalikan sistem
 2. Tahapan pengembangan Software : Memilih Model
Life Cycle – Karakteristik Proyek Kategori Matrix
Requirements

Requirements Waterfall Prototype Spiral RAD

Apakah kebutuhan gampang
Yes No No Yes
didefinisikan atau mudah diketahui?
Dapatkan requirement
didefinisikan dalam siklus awal ? Yes No No Yes

Akankah kemudian kebutuhan

No Yes Yes No
bisa berubah dalam siklus ?
Adakah kebutuhan
mendemonstrasikan kebutuhan No Yes Yes Yes
untuk mendapatkan definisi ?

Apakah pembuktian konsep No Yes Yes Yes

dibutuhkan utk mendemonstrasikan
kapabilitas s/w ?
2. Tahapan pengembangan Software : Memilih Model
Life Cycle – Karakteristik Proyek Kategori Matrix Project
Team
Project Team Waterfall Prototype Spiral RAD
Apakah sebagian besar anggota tim
baru dalam problem domain untuk No Yes Yes No
proyek ini ?

Apakah sebagian besar anggota tim

baru terhadap teknologi domain untuk Yes No Yes No
proyek ini?

Apakah sebagian besar anggota tim

baru terhadap tools yang digunakan Yes No Yes No
dalam project ini ?

Apakah anggota tim dapat diubah

penugasannya dalam siklus No Yes Yes No
perancangan ?

Apakah ada pelatihan bagi anggota tim

dalam proyek ini ? No No No Yes
 2. Tahapan pengembangan Software : Memilih Model
Life Cycle – Karakteristik Proyek Kategori Matrix User
Community
User Community Waterfall Prototype Spiral RAD

Akankah ketersediaan pengguna dibatasi,

atau terbatas selama siklus perancangan Yes No Yes No
?

Apakah user baru mengetahui tentang

No Yes Yes No
system definition?
Apakah user sangat ahli dalam problem
domain? No Yes No Yes

Apakah user mau melewati semua fase No Yes No Yes

dalam siklus perancangan sistem?
 Memilih Model Life Cycle – Karakteristik Proyek Kategori
Matrix Tipe dan Resiko
Project Type & Risk Waterfall Prototype Spiral RAD

Does the project identify a new product

direction for the organization? No Yes Yes No

Is the project a system integration

project? No Yes Yes Yes

Is the project an enhancement to an

existing system? No No No Yes

Is the funding for the project expected to

Yes Yes No Yes
be stable throughout the life cycle?

Is the product expected to have a long Yes No Yes No

life in the organization?
2. Tahapan pengembangan Software : Umumnya
kita menggunakan System Development Life Cycle
(SDLC)

System Requirements Architectural

Specification Analysis Design

Unit Testing Coding & Detailed

Debugging Design

System
Maintenance
Testing
3. Teknik, model dan metode
pengembangan Perangkat Lunak
Metode Pengembangan S/W :
1. Requirement Analysis
2. Domain analysis
3. Behavior Modeling : use case and
context diagram
4. Structural Modeling : Class Diagram
5. Dynamic Modelling : sequence
diagram
6. Desain
3. Teknik, model dan metode
pengembangan Perangkat Lunak
Metode Pengembangan S/W :
1. Requirement Analysis
Aspect-Oriented
Requirements

Object-Oriented
Analysis & Design

Requirements Requirements Requirements

gathering analysis specification

Structured
Analysis & Design

Agile Development
User Stories
3. Teknik, model dan metode
pengembangan Perangkat Lunak
1. Requirement Analysis
Problem domain Software (Solution) domain

Describes

Specifi
Requirements Program
Customer cation

Specifies

Analyzes Develops

Software Engineer
3. Teknik, model dan metode
pengembangan Perangkat Lunak
Metode Pengembangan S/W :
1. Memahami kebutuhan (contoh mesin
ATM)

1
7
4
0
2
5 3
8 6
9
Communication link

Bank’s
remote
ATM machine
datacenter
Bank
customer

35
Bagaimana Mesin ATM bekerja
Domain Model

Transaction
How may I record
help you? Cash

Bookkeeper
Speakerphone Safe
Safe keeper
Phone

Window clerk

Datacenter
liaison

Dispenser

Bank’s
remote
datacenter
Customer
36
 : Bagaimana Mesin ATM
Komik

bekerja
A Enter B C Verify
account
D
your PIN
XYZ
Verify
this
account

Typing in XYZ valid. Account

PIN number Balance: valid.
… $100 Balance:
$100

E How may F Release

G Record
I help $60 $60 less
you?

Withdraw Dispense
H Dispensing!

$60 $60
Please take
your cash

37
ATM: Gallery of Players

1
4 2
7 5 3
8 6
0 9

Bank customer System Bank’s remote

(ATM machine) datacenter

Aktor (Easy to identify because they are visible!)

38
Gallery of Workers + Tools

Window clerk Datacenter Bookkeeper Safe keeper Dispenser

liaison

Speakerphone Telephone Transaction Safe Cash

record

Konsep (Hard to identify because they are invisible/imaginary!)

39
Studi Kasus : Ambil Uang Cash
A Enter
B Verify
account C How may
your PIN XYZ I help
you?

1
4 2
7 5 3 1
8 6 4 2
0 9 7 5 63
8
0 9

Typing in XYZ valid. Withdraw

PIN number Balance: $60
… $100

D E XYZ
Please take
your cash withdrew
$60

1
4 2
7 5 63
8
0 9

Collecting
cash …
Acknowledged

40
Contoh User Stories
Identifier User Story Size

As an authorized person (tenant or landlord), I can keep the doors locked at all
ST-1 4 points
times.

ST-2 As an authorized person (tenant or landlord), I can lock the doors on demand. 3 pts

ST-3 The lock should be automatically locked after a defined period of time. 6 pts

As an authorized person (tenant or landlord), I can unlock the doors.

ST-4 9 points
(Test: Allow a small number of mistakes, say three.)

ST-5 As a landlord, I can at runtime manage authorized persons. 10 pts

ST-6 As an authorized person (tenant or landlord), I can view past accesses. 6 pts

ST-7 As a tenant, I can configure the preferences for activation of various devices. 6 pts

ST-8 As a tenant, I can file complaint about “suspicious” accesses. 6 pts

• Note no priorities for user stories.

• Story priority is given by its order of appearance on the work backlog (described next)
• Size points (last column) will be described later
41
 Contoh Hasil Requirement
Analysis
Identifier Priority Requirement
The system shall keep the door locked at all times, unless commanded otherwise by
REQ1 5 authorized user. When the lock is disarmed, a countdown shall be initiated at the end
of which the lock shall be automatically armed (if still disarmed).
REQ2 2 The system shall lock the door when commanded by pressing a dedicated button.
REQ3 5 The system shall, given a valid key code, unlock the door and activate other devices.
The system should allow mistakes while entering the key code. However, to resist “dictionary
REQ4 4 attacks,” the number of allowed failed attempts shall be small, say three, after which the system
will block and the alarm bell shall be sounded.
REQ5 2 The system shall maintain a history log of all attempted accesses for later review.
REQ6 2 The system should allow adding new authorized persons at runtime or removing existing ones.
The system shall allow configuring the preferences for device activation when the user provides a
REQ7 2
valid key code, as well as when a burglary attempt is detected.
The system should allow searching the history log by specifying one or more of these parameters:
REQ8 1 the time frame, the actor role, the door location, or the event type (unlock, lock, power failure, etc.).
This function shall be available over the Web by pointing a browser to a specified URL.
The system should allow filing inquiries about “suspicious” accesses. This function shall be
REQ9 1
available over the Web.
3. Teknik, model dan metode
pengembangan Perangkat Lunak
Metode Pengembangan S/W :
2. Domain analysis
3. Teknik, model dan metode
pengembangan Perangkat Lunak
Metode Pengembangan S/W :
2. Domain analysis
3. Teknik, model dan metode
pengembangan Perangkat Lunak
Metode Pengembangan S/W :
2. Domain analysis
3. Teknik, model dan metode
pengembangan Perangkat Lunak
Metode Pengembangan S/W :
2. Domain analysis
3. Teknik, model dan metode
pengembangan Perangkat Lunak
Metode Pengembangan S/W :
2. Domain analysis , Contoh Hasil :
Domain dictionary

Domain definition
Penentuan Domain Anaysis : Bagaimana
Pemula membagi Pekerjaannya

List the components of the system-to-be

Each sub-group of one or more team members is
assigned a different component to develop
 One or more team members is assigned to
“write documentation”

User Interface Business Logic Database/ Documentation

and Algorithms Network

“Chain” organization—every link is critical

If any link fails, the whole project fails
 Separation of concerns is impossible
48
 Dekomposisi:
Projection vs. Partitioning

Projection: :Partitioning

Projection-based decomposition helps us understand the components

49
in the context of their use, relative to other parts of the system.
 Contoh : Otomatisasi Dekomposisi
Restoran dengan Teknik Partitioning
Developer Team α Developer Team Φ

Subgroup α-RED Subgroup α-GREEN Subgroup α-BLUE Subgroup α-PURPLE

Business Logic Database/

User Interface Documentation
and Algorithms Network 50
Contoh : Otomatisasi Restoran
Beban Komunikasi
Developer Team α Developer Team Φ

Function-1:
description
Function-2:
Interface for description Tables for
what functions? … what data?
What to
write about?

Business Logic Database/

User Interface Documentation
and Algorithms Network 51
 Contoh : Otomatisasi Dekomposisi
Restoran dengan Teknik Projection
Developer Team α Developer Team Φ

Different way of “slicing” Subgroup Subgroup Subgroup

Φ-RED Φ-GREEN Φ-BLUE
the project:
 Instead of horizontal
slicing, we have vertical
slicing—”stacks” Customer-related
functions
Each “stack” can be done
independently of other Kitchen-related
stacks, functions
as a mini-project
Management-
 Separation of concerns! related
functions
52
Shared Infrastructure
 Contoh : Otomatisasi Dekomposisi
Restoran dengan Teknik Projection
Developer Team α Developer Team Φ

Team communication is
simple: Subgroup Subgroup Subgroup
What do we have Φ-RED Φ-GREEN Φ-BLUE
They only need to define in common?

shared interfaces (“APIs”)

and can focus on creative
software development Customer-related
functions
What is inside of each “stack”
is not discussed with other
sub-teams Kitchen-related
—for others, the contents of functions
your “stack” is hidden—they
see a black box with defined
interface / APIs Management-
(“information hiding”) related
functions
53
Shared Infrastructure
3. Teknik, model dan metode
pengembangan Perangkat Lunak
Metode Pengembangan S/W :
2. MODELING
3. Teknik, model dan metode
pengembangan Perangkat Lunak
Metode Pengembangan S/W :
3. Behavior Modeling : use case and
context diagram
 3. Behavior Modeling : Membuat Use
Cases dari System Requirements 1
REQ1: Keep door locked and auto-lock 2
REQ2: Lock w hen “LOCK” pressed 3
4
REQ3: Unlock w hen valid key provided
5
REQ4: Allow mistakes but prevent dictionary attacks X
REQ5: Maintain a history log Y
REQ6: Adding/removing users at runtime
REQ7: Configuring the device activation preferences
REQ8: Inspecting the access history
REQ9: Filing inquiries

Actor Actor’s Goal (what the actor intends to accomplish) Use Case Name
Landlord To disarm the lock and enter, and get space lighted up. Unlock (UC-1)
Landlord To lock the door & shut the lights (sometimes?). Lock (UC-2)
Landlord To create a new user account and allow access to home. AddUser (UC-3)
Landlord To retire an existing user account and disable access. RemoveUser (UC-4)
To find out who accessed the home in a given interval of
Tenant InspectAccessHistory (UC-5)
time and potentially file complaints.
Tenant To disarm the lock and enter, and get space lighted up. Unlock (UC-1)
Tenant To lock the door & shut the lights (sometimes?). Lock (UC-2)
Tenant To configure the device activation preferences. SetDevicePrefs (UC-6)
LockDevice To control the physical lock mechanism. UC-1, UC-2
LightSwitch To control the lightbulb. UC-1, UC-2
[to be To auto-lock the door if it is left unlocked for a given
AutoLock (UC-2)
identified] interval of time.

( Actors already given if working from user stories instead of system requirements )
 3. Behavior Modeling : Use Case Diagram
- Device Control UC1:
UC2:
Unlock
Lock
UC3: AddUser
UC4: RemoveUser
UC5: InspectAccessHistory
UC6: SetDevicePrefs
UC7: AuthenticateUser
UC8: Login

system
boundary First tier use cases Second tier use cases

actor lude
» UC7: AuthenticateUser
«inc
«participate»
«initiate» »
UC1: Unlock t i c i pate
r
«pa
«in
it «particip LockDevice
iat ate»
e»
Tenant
ate»
e» «particip
i t iat
«in
«pa LightSwitch
rtici
«initiate» UC2: Lock pate
»
«initiate + participate»
communication use case
Landlord Timer
3. Behavior Modeling : Use Case Diagram
- Account Management UC1:
UC2:
Unlock
Lock
UC3: AddUser
UC4: RemoveUser
UC5: InspectAccessHistory
UC6: SetDevicePrefs
UC7: AuthenticateUser
UC8: Login

Account Management Subsystem

«initiate»
UC3: AddUser
« in
«ini clu
tia te » de
»
Landlord »
te «incl
p a UC4: RemoveUser ud e»
t ici
par
« UC8: Login
lu de »
« inc
t e»
«initia UC5: InspectAccessHistory
d e»
u
n cl
«initi
ate» «i

Tenant UC6: SetDevicePrefs

3. Behavior Modeling : Contoh GUI untuk
UC6: Set Device Pref’s
Device Preferences
File Configure Help

Activate for valid key Activate for burglary attempt

Lights Air-conditioning Alarm bell Send SMS

Music Heating Police …

Apply Close

( NOTE: Lock device is mandatory, not an option )

3. Behavior Modeling : Contoh Use Case
1- Unlock
Use Case UC-1: Unlock

Related REQ1, REQ3, REQ4, and REQ5 stated in Table 2-1

Requirem’ts:
Initiating Actor: Any of: Tenant, Landlord
Actor’s Goal: To disarm the lock and enter, and get space lighted up automatically.
Participating LockDevice, LightSwitch, Timer
Actors:
• The set of valid keys stored in the system database is non-empty.
Preconditions: • The system displays the menu of available functions; at the door keypad the menu
choices are “Lock” and “Unlock.”
Postconditions: The auto-lock timer has started countdown from autoLockInterval.
Flow of Events for Main Success Scenario:
 1. Tenant/Landlord arrives at the door and selects the menu item “Unlock”
2. include::AuthenticateUser (UC-7)
 3. System (a) signals to the Tenant/Landlord the lock status, e.g., “disarmed,” (b) signals to
LockDevice to disarm the lock, and (c) signals to LightSwitch to turn the light on
 4. System signals to the Timer to start the auto-lock timer countdown
 5. Tenant/Landlord opens the door, enters the home [and shuts the door and locks]
3. Behavior Modeling : Contoh Subroutine
«include» Use Case
Use Case UC-7: AuthenticateUser (sub-use case)
Related REQ3, REQ4 stated in Table 2-1
Requirements:
Initiating Actor: Any of: Tenant, Landlord
Actor’s Goal: To be positively identified by the system (at the door interface).
Participating AlarmBell, Police
Actors:
• The set of valid keys stored in the system database is non-empty.
Preconditions:
• The counter of authentication attempts equals zero.
Postconditions: None worth mentioning.

Flow of Events for Main Success Scenario:

 1. System prompts the actor for identification, e.g., alphanumeric key
 2. Tenant/Landlord supplies a valid identification key
 3. System (a) verifies that the key is valid, and (b) signals to the actor the key validity
Flow of Events for Extensions (Alternate Scenarios):
2a. Tenant/Landlord enters an invalid identification key
 1. System (a) detects error, (b) marks a failed attempt, and (c) signals to the actor
System (a) detects that the count of failed attempts exceeds the maximum allowed
 1a. number, (b) signals to sound AlarmBell, and (c) notifies the Police actor of a
possible break-in
 2. Tenant/Landlord supplies a valid identification key
3. Same as in Step 3 above
3. Behavior Modeling : Acceptance Test
Case untuk UC-7 Authenticate User

Test-case Identifier: TC-1

Use Case Tested: UC-1, main success scenario, and UC-7

The test passes if the user enters a key that is contained in

Pass/fail Criteria: the database, with less than a maximum allowed number of
unsuccessful attempts

Input Data: Numeric keycode, door identifier

Test Procedure: Expected Result:

Step 1. Type in an incorrect System beeps to indicate failure;

keycode and a valid door records unsuccessful attempt in the database;
identifier prompts the user to try again

Step 2. Type in the correct System flashes a green light to indicate success;
records successful access in the database;
keycode and door identifier disarms the lock device
 3. Behavior Modeling : Use Case 2 - Lock
Use Case UC-2: Lock
Related REQ1, REQ2, and REQ5 stated in Table 2-1
Requirements:
Initiating Actor: Any of: Tenant, Landlord, or Timer
Actor’s Goal: To lock the door & get the lights shut automatically (?)
Participating LockDevice, LightSwitch, Timer
Actors:
Preconditions: The system always displays the menu of available functions.
Postconditions: The door is closed and lock armed & the auto-lock timer is reset.
Flow of Events for Main Success Scenario:
 1. Tenant/Landlord selects the menu item “Lock”
System (a) signals affirmation, e.g., “lock armed,” (b) signals to LockDevice to arm the lock (if
 2. not already armed), (c) signal to Timer to reset the auto-lock counter, and (d) signals to
LightSwitch to turn the light off (?)
Flow of Events for Extensions (Alternate Scenarios):
2a. System senses that the door is not closed, so the lock cannot be armed
 1. System (a) signals a warning that the door is open, and (b) signal to Timer to start the alarm
counter
 2. Tenant/Landlord closes the door
System (a) senses the closure, (b) signals affirmation to the Tenant/Landlord, (c) signals to
 3. LockDevice to arm the lock, (d) signal to Timer to reset the auto-lock counter, and (e) signal to
Timer to reset the alarm counter
3. Behavior Modeling : Diagram Konteks
Diagram konteks
adalah diagram yang
terdiri dari suatu
proses dan
menggambarkan
ruang lingkup suatu
sistem. Diagram
konteks merupakan
level tertinggi dari
DFD yang
menggambarkan
seluruh input ke
dalam sistem atau
output dari sistem
yang memberi
gambaran tentang
keseluruhan sistem.
3. Behavior Modeling : Diagram Aktivitas

Activity diagram, adalah

diagram ini
menggambarkan tentang
aktifitas yang terjadi pada
sistem. Dari pertama
sampai akhir, diagram ini
menunjukkan langkah –
langkah dalam proses kerja
sistem yang kita buat.
Behavior Modeling : Diagram Aktivitas
Initial
node
Select
“Unlock”

1
2 Enter Key
3 Action
4
5 Decision
X Verify Key
Y

[authorized] [not authorized]

Signal
Success
Notify
Intrusion
Open Lock &
Lit Light
Sound Alarm

Start Autolock
Timer

Activity
Merge
final node
CONTOH LAIN :
3. Teknik, model dan metode
pengembangan Perangkat Lunak
Metode Pengembangan S/W :
4. Structural Modeling : Class Diagram

Class diagram adalah model statis yang

menggambarkan struktur dan deskripsi class serta
hubungannya antara class. Class diagram mirip
ER-Diagram pada perancangan database, bedanya
pada ER-diagram tdk terdapat operasi/metode tapi
hanya atribut. Class terdiri dari nama kelas, atribut
dan operasi/metode.
3. Teknik, model dan metode
pengembangan Perangkat Lunak
Metode Pengembangan S/W :
4. Structural Modeling : Contoh Class
Diagram
3. Teknik, model dan metode
pengembangan Perangkat Lunak
Metode Pengembangan S/W : 5. Dynamic Modelling
- Sequence diagram

Sequence diagram adalah suatu penyajian

perilaku yang tersusun sebagai langkah-langkah
percontohan dari waktu ke waktu. Sequence
diagram digunakan untuk arus pekerjaan, pesan
yang disampaikan dan bagaimana elemen-
elemen di dalamnya bekerja sama dari waktu ke
waktu untuk mencapai suatu tujuan.
 Metode Pengembangan S/W : System Sequence
Diagram [Modeling System Workflows]
Use case: Unlock
: System
User LockDevice LightSwitch Timer
«initiating actor» «supporting actor» «supporting actor» «offstage actor»
select function(“unlock")

prompt for the key

enter key
verify key

signal: valid key, lock open

open the lock

turn on the light

start ("duration“)

Main success scenario

Similar to UML sequence diagrams,

but for actor interactions instead of software object interactions
Metode Pengembangan S/W : System Sequence
Diagram [Modeling System Workflows]
Use case: Unlock

: System
User AlarmBell Police
«initiating actor» «supporting actor» «offstage actor»
select function(“unlock")

loop prompt for the key

enter key
verify key

signal: invalid key

prompt to try again
sound alarm

notify intrusion

Alternate scenario (burglary attempt)

3. Teknik, model dan metode
pengembangan Perangkat Lunak
3. Teknik, model dan metode
pengembangan Perangkat Lunak
Metode Pengembangan S/W :
6. Desain Sistem
Metode Pengembangan S/W :
6. Desain Sistem
Metode Pengembangan S/W :
6. Desain Sistem
Metode Pengembangan S/W :
6. Desain Sistem
Metode Pengembangan S/W :
6. Desain Sistem
Metode Pengembangan S/W :
6. Desain Sistem - Desain Dataset
Metode Pengembangan S/W :
6. Desain Sistem - Desain Kendali Aplikasi
Selamat Berkarya
GUNADARMA !