Software Engineering:

2. Process

Romi Satria Wahono

romi@romisatriawahono.net
http://romisatriawahono.net/se
WA/SMS: +6281586220090

1
Romi Satria Wahono
• SD Sompok Semarang (1987)
• SMPN 8 Semarang (1990)
• SMA Taruna Nusantara Magelang (1993)
• B.Eng, M.Eng and Ph.D in Software Engineering from
Saitama University Japan (1994-2004)
Universiti Teknikal Malaysia Melaka (2014)
• Research Interests: Software Engineering,
Machine Learning
• Founder dan Koordinator IlmuKomputer.Com
• Peneliti LIPI (2004-2007)
• Founder dan CEO PT Brainmatics Cipta Informatika
2
Course Outline

1. Introduction

2. Process

3. Methodology

4. Quality

5. Research

3
2. Process
2.1 Software Development Life Cycle
2.2 Software Effort Estimation
2.1 Software Development Life
Cycle

5
2.1.1 Planning

6
When Do Software Projects Begin?
• When someone sees an opportunity to
create business value from using information
technology

• Then he or she creates a system request

• Feasibility analysis is used to aid in the

decision of whether or not to proceed with
the project
7
Software Development Life Cycle (SDLC)

Planning

Implementation Analysis

Design (Dennis, 2012)

8
Software Development Life Cycle
(SDLC)
1. Planning: Why build the system?
• System request, feasibility analysis

2. Analysis: Who, what, when, where will the system be?

• Requirement gathering, business process modeling

3. Design: How will the system work?

• Program design, user interface design, data design

4. Implementation: System construction and delivery

• System construction, testing, documentation and
installation
9
 1. Planning – System Request
Elemen Deskripsi Contoh
Business The business-related Increase sales
Need reason for initiating the Improve market share
software development Improve access to information
project Improve customer service
Decrease product defects
Streamline supply acquisition processes

Business The business capabilities Provide onIine access to information

Requirements that software will Capture customer demographic information
provide Include product search capabilities
Produce management reports
Include online user support

Business The benefits that the 3% increase in sales

Value software will create for % increase in market share
the organization 10% operational cost reduction
$200,000 cost savings from decreased supply costs
$150,000 savings from removal of existing system

10
11
System Request – Case Study
Menu Utama
1. Melihat Saldo
2. Mentransfer Uang
3. Mengambil Uang
4. Logout

Kotak Uang Kotak Kartu

Kotak Kuitansi

12
 System Request – Online ATM System
Project Sponsor: Margaret Mooney, Vice President of Marketing
Business Need: Project ini dibuat dengan tujuan untuk mendapatkan pelanggan
baru yang menggunakan Internet dam memberikan layanan yang
lebih baik ke pelanggan yang ada melalui layanan berbasis Internet
Business Requirements:
Dengan menggunakan Online ATM System, pelanggan dapat melakukan seluruh
transaksi perbankan. Fitur utama yang ada pada sistem ini adalah:
1. Pengecekan Saldo
2. Pengiriman Uang
3. Transaksi Pembayaran Tagihan

Business Value:
Keuntungan Intangible:
- Meningkatkan layanan ke pelanggan
- Mengurangi komplen dari pelanggan

Keuntungan Tangible:
- $750,000 transaksi keuangan dari pelangan baru
- $1,875,000 transaksi keuangan dari pelanggan lama
- $50,000 pengurangan biaya telepon untuk melayani pelanggan

13
Latihan Studi Kasus
• Buat System Request untuk aplikasi yang
dibutuhan oleh suatu organisasi

• Pikirkan baik-baik, keuntungan yang didapat

(business value) dari penerapan system
tersebut di organisasi

14
2. Planning - Feasibility Analysis
1. Technical feasibility: Can we build it?

2. Economic feasibility: Should we build it?

3. Organizational feasibility: If we build it, will

they come?

15
 2. Planning - Feasibility Analysis
1 Technical • Familiarity with application: Less familiarity generates more risk
Feasibility • Familiarity with technology: Less familiarity generates more risk
• Project size: Large projects have more risk
• Compatibility: The harder it is to integrate the system with the
company’s existing technology, the higher the risk will be
2 Economic • Return on Investment (ROI)
Feasibility • Break Even Point (BEP)
• Intangible Benefit
3 Organizational • Is the software project strategically aligned with the
Feasibility business?

16
 Feasibility Analysis - Technical
Feasibility
Familiarity with • Knowledge of business domain
application • Need to understand improvements
• Need to recognize pitfalls and bad ideas
Familiarity with • Is technology new to this organization?
technology • Is this a brand new technology?
• Extension of existing firm technologies
Project size • Number of people, time, and features
Compatibility • Systems are not built in a vacuum
• Needs to integrate with current systems and data

17
18
Feasibility Analysis - Economic
Feasibility

19
20
Present Value (PV)
• The amount of an investment today compared
to the same amount n years in the future
• Taking into account inflation and time

Amount
PV =
(1 + Interest Rate)n

21
Net Present Value

537,201
1  0.035

 463,395

22
Net Present Value (NPV)
The present value of benefit less the
present value of cost

NPV = PV Benefits – PV Costs

23
NPV Calculation

3,204,752  2,575,331
 629,421



24
Return on Investment (ROI)
The Amount of revenue or cost savings
results from a given investment

ROI = Total Benefits – Total Costs

Total Costs

25
ROI Calculation

3,204,752  2,575,331
2,575,331
 0.2444

26
Break Even Point (BEP)
The point in time when the costs of the
project equal the value it has delivered

Yearly NPV* – Cumulative NPV

BEP =
Yearly* NPV

* Use the yearly NPV amount from the first year in which
project has positive cash flow

27
Break Even Point (BEP)

28
Cash Flow Plan

29
Feasibility Analysis - Organizational Feasibility

• Strategic Alignment
• How well does the project match up with the
business strategy?

• Stakeholder analysis considers

• Project champion(s)
• Organizational management
• System users
• Anybody affected by the change

30
 Stakeholder Analysis Considers
• Project champion(s)
• High-level non-IS executive
• Shepherds project to completion
• It's good to have more than one
• Organizational management
• Need this support to sell system to organization
• System users
• In the loop so end system meets needs

31
Feasibility Analysis – Case Study
1. Technical feasibility
2. Economic feasibility
3. Organizational feasibility

32
 Feasibility Analysis - Online ATM System
Margaret Mooney and Alec Adams created the following feasibility analysis
for the Online ATM System Project.

1. Technical Feasibility
The Online ATM System is feasible technically, although there is some risk.
1.1 Online ATM System’s risk regarding familiarity with the application is high
• The Marketing Department has little experience with Internet-based marketing and sales
• The IT Department has strong knowledge of the company’s existing ATM systems,
however, it has not worked with Web-enabled ATM systems.
1.2 Online ATM System’s risk regarding familiarity with the technology is medium
• The IT Department has relied on external consultants to develop its existing Web env.
• The IT Department has learned about Web technology by maintaining the corporate site
1.3 The project size is considered medium risk
• The project team likely will include less than ten people
• Business user involvement will be required
• The project timeframe cannot exceed a year and it should be much shorter
1.4 The compatibility with existing technical infrastructure should be good
• The current ATM System is a client-server system built using open standards. An interface
with the Web should be possible
• Retail bank already place and maintain orders electronically
• An Internet infrastructure already is in place at retail bank and at the corporate
headquarters

33
2. Economic Feasibility
• A cost–benefit analysis was performed. A conservative approach shows that the
Online ATM System has a good chance of adding to the bottom line of the company
significantly.
• Return on Investment (ROI) over 3 years: 229 percent
• Break-even point (BEP) occurs: after 1.7 years
• Total benefit after three years: $3.5 million

• Intangible Costs and Benefits

• Improved customer satisfaction
• Greater brand recognition

3. Organizational Feasibility
• From an organizational perspective, this project has low risk. The objective of the
system, which is to increase sales, is aligned well with the senior management’s goal
of increasing sales for the company. The move to the Internet also aligns with
Marketing’s goal to become more savvy in Internet marketing and sales.
• The project has a project champion, Margaret Mooney, Vice President of Marketing.
Margaret is well positioned to sponsor this project and to educate the rest of the
senior management team when necessary. Much of senior management is aware of
and supports the initiative.

34
 2003 2004 2005 Total
Increased sales from new customers 0 750,000 772,500
Increased sales from existing customers 0 1,875,000 1,931,250
Reduction in customer complaint calls 0 50,000 50,000
Total Benefits: 0 2,675,000 2,753,750
PV of Benefits: 0 2,521,444 2,520,071 5,041,515
PV of All Benefits: 0 2,521,444 5,041,515
Labor: Analysis, Design and Implementation 162,000 0 0
Consultant Fees 50,000 0 0
Office Space and Equipment 7,000 0 0
Software and Hardware 35,000 0 0
Total Development Costs: 254,000 0 0
Labor: Webmaster 85,000 87,550 90,177
Labor: Network Technician 60,000 61,800 63,654
Labor: Computer Operations 50,000 51,500 53,045
Labor: Business Manager 60,000 61,800 63,654
Labor: Assistant Manager 45,000 46,350 47,741
Labor: 3 Staff 90,000 92,700 95,481
Software upgrades and licenses 4,000 1,000 1,000
Hardware upgrades 5,000 3,000 3,000
User training 2,000 1,000 1,000
Communications charges 20,000 20,000 20,000
Marketing expenses 25,000 25,000 25,000
Total Operational Costs: 446,000 452,700 464,751
Total Costs: 700,000 452,700 464,751
PV of Costs: 679,612 426,713 425,313 1,531,638
PV of all Costs: 679,612 1,106,325 1,531,638
Total Project Costs Less Benefits: (700,000) 2,222,300 2,288,999
Yearly NPV: (679,612) 2,094,731 2,094,758 3,509,878
Cumulative NPV: (679,612) 1,415,119 3,509,878
Return on Investment (ROI): 229.16% (3,509,878/1,531,638)
Break-even Point (BEP): 1.32 years (BEP in Year 2 = [2,094,731 – 1,415,119] / 2,094,731 = 0.32)
35
Latihan Studi Kasus
• Lakukan Feasibility Analysis untuk System
Request yang dibuat

36
2.1.2 Analysis and Design

37
 Analysis Design Paradigm and
Diagrams
Paradigm Diagrams
1 Data-oriented DFD
2 Process-oriented Flowchart
3 Object-oriented UML
(data + process)

38
 Sejarah UML
Booch, Jacobson, Rumbaugh
• In the 90s many people
creating OO diagramming languages
• Three different ones created by Grady Booch, Ivar
Jacobson, James Rumbaugh
• Joined forces with
Rational (company) to
create Unified Modeling
Langauge (UML)

39
 2011  UML 2.4
Sejarah UML 2003  UML 2.0

40
What is the UML?
• UML: Unified Modeling Language
• UML can be used for modeling all processes in
the development life cycle and across
different implementation technologies
(technology and language independent)
• UML is the standard language for visualizing,
specifying, constructing, and documenting the
artifacts of a software-intensive system
• UML is a communication tool – for the team,
and other stakeholders
41
The Triangle of Success in Software Dev.

Notation:
Standard

Process: Tools:
Customer- Support
Oriented Standard and
Methodology Process

42
UML Tools
• Rational Rose
• Visual Paradigm
• Enterprise Architect
• Microsoft Visio
• Star UML
• Netbeans UML Plugin

43
UML 2.0 Diagrams
UML version 2.0 has 14 diagrams in 2 major
groups:
1. Structure Diagrams
2. Behavior Diagrams

44
UML 2.0 Diagram

45
UML Structure Diagrams
Represent the data and static
relationships in an information system
1. Class Diagram
2. Object Diagram
3. Package Diagram
4. Deployment Diagram
5. Component Diagram
6. Composite Structure Diagram

46
Structure Diagrams
1. Class Diagrams
• Common vocabulary used by analyst and users
• Represent things (employee, paycheck,…)
• Shows the relationships between classes
2. Object Diagrams
• Similar to class diagrams
• Instantiation of a class diagram
• Relationships between objects
3. Package Diagrams
• Group UML elements together to form higher level
constructs

47
Structure Diagrams
4. Deployment Diagrams
• Shows the physical architecture and software
components of system
• For example, network nodes
5. Component Diagrams
• Physical relationships among software
components
• Example – Client/Server (Which machines run
which software)
6. Composite Structure
• Illustrates internal structure of a complex class
48
UML Behavior Diagrams
Depict the dynamic relationships among the
instances or objects that represent the
business information system

1. Activity Diagram 5. Timing Diagram

2. Sequence Diagram 6. Behavior State Machine
3. Communication Diagram 7. Protocol State Machine
4. Interaction Diagram 8. Use Case Diagrams

49
Behavior Diagrams
1. Activity Diagrams
• Model processes in an information system
• Example: Business workflows, business logic
2. Interaction Diagrams
• Shows interaction among objects
3. Sequence Diagrams
• Time-based ordering of the interaction
4. Communication Diagrams
• Communication among a set of collaborating objects of
an activity

50
Behavior Diagrams
5. Interaction Diagrams
• Overview of flow of control of a process
6. Timing Diagrams
• Show how an object changes over time
7. State Machines
• Examines behavior of one class
• Models the different states and state transitions an
object can experience
8. Use-Case Diagrams
• Shows interaction between the system and environment
• Captures business requirements

51
UML Problems
1. UML is modeling notation, it is not a
development process or a methodology
• UML driven development process?

2. UML is too complex, difficult to understand

quickly
• Should we use all UML diagrams?

52
UML Process (EA Sparx)
1. Display the boundary of a system and its
major functions using use cases and actors
2. Model the organization’s business process
with activity diagram
3. Illustrate use case realizations with sequence
diagrams
4. Represent a static structure of a system using
class diagrams
5. Reveal the physical implementation
architecture with deployment diagrams
53
UML Process (EA Sparx)
1. Use Cases Diagram
2. Activity Diagram
3. Sequence Diagram
4. Class Diagram
5. Deployment Diagrams

54
 UML Process (Kendal, 2011)
1. A use case diagram, describing how the system is used.
Analysts start with a use case diagram
2. An activity diagram, illustrating the overall flow of
activities. Each use case may create one activity diagram
3. Sequence diagrams, showing the sequence of activities
and class relationships. Each use case may create one or
more sequence diagrams
4. Class diagrams, showing the classes and relationships.
Sequence diagrams are used to determine classes
5. Statechart diagrams, showing the state transitions. Each
class may create a statechart diagram, which is useful
for determining class methods
55
56 (Kendall and Kendall, 2011)
UML Process (Barclay, 2004)

57
System Analysis and Design with
UML
1. System Analysis
1. Business Process Identification
 Use Case Diagram
2. Business Process Modeling
 Activity Diagram or Business Process Modeling Notation (BPMN)
3. Business Process Realization
 Sequence Diagram (Buat untuk setiap use case dengan menggunakan pola Boundary-Control-Entity)

2. System Design
1. Program Design
1. Class Diagram (Gabungkan Boundary-Control-Entity Class dan susun story dari sistem yang dibangun)
2. Package Diagram (Gabungan class yang sesuai, boleh menggunakan pola B-C-E)
3. Deployment Diagram (arsitektur software dari sistem yang dibangun)
2. User Interface Design (Buat UI design dari Boundary Class)
3. Entity-Relationship Model (Buat ER diagram dari Entity Class)

58
 SDLC and Artifacts
1. Planning System
1.1 System Request
1.2 Feasibility Analysis
Proposal
2. Analysis
2.1 Use Case Diagram
2.2 Activity Diagram
2.3 Sequence Diagram System
3. Design Specification
3.1 Class Diagram
3.2 Deployment Diagram
3.3 User Interface Design
3.4 Data Model
New
4. Implementation
4.1 Program Code
Software
4.2 Testing Plan
4.3 Documentation 59
Use Case Diagram

60
Use Case Diagrams

• Summarized into a single picture

• All of the use cases for the part of the
system being modeled
• Use case represents the discrete activities
performed by the user
• Use Case Diagram tells what the system
will do
• Good for communicating with users
61
Syntax for an Use Case Diagram
• Actor
• person or system that derives benefit
from and is external to the subject
• Use Case
• Represents a major piece of system
functionality
• Association Relationship
• Include Relationship <<includes>>

• Extend Relationship <<extends>>

• Generalization Relationship
62
Use Case
• A major piece of
system functionality
Use Case
• Can extend other
Use Cases
• Placed inside system boundary
• Labeled with descriptive
verb - noun phrase

63
System Boundary
• Includes the name Boundary
of the system
inside or on top
• Represents the
scope of the system
• Actors are outside the scope of the system

64
Actor
• A person or another
system that interacts
with the current system
• A role, not a specific user
actor
• Provides input, Actor/Role
receives output, or both

65
Association Relationship
• Links actor and the Use Case
• Shows two-way communication
• If one-way, arrows are used
• * is for "multiplicity of the Association"

* *
66
Extends Relationship
• Extends Use Case to include Optional
behavior
• Arrow points from the extension Use Case to
the base Use Case

extend

Make Payment extend Make

Arrangement Appointment

67
Include Relationship
• Include one Use Case from within another
• Arrow points from base Use Case to the
included Use Case

include

Make New include Create New

Patient Appointment Patient
68
 Generalization Relationship
• A specialized Use Case to a more
generalized Use Case
• Arrow points from specialized to general
Use Case

Make Old Make

Appointment Appointment

69
Use Case Diagram for Appointment System

70
Use Case Diagram with Specialized Actor

71
Extend and Include Relationships

72
Use Case Diagram – Case Study
uc UCD Sistem ATM

Online ATM System

Memasukan PIN

Mengecek Saldo

Sistem Core Banking

Nasabah

Mengirim Uang

Melakukan Logout

73
Latihan Studi Kasus
• Pahami kembali System Request yang sudah
dibuat
• Lanjutkan dengan membuat Use Case
Diagram dari System Request yang dibuat

74
Activity Diagram

75
Syntax for an Activity Diagram

76
Activity Diagram Example

77
Syntax for an Activity Diagram

78
2. Activity Diagram: Memasukkan PIN
act 2 AD Memasukan PIN

Nasabah Sistem ATM

Mulai

Memasukan PIN Memv alidasi

di Menu PIN PIN

tidak
PIN Valid?

tidak
ya

Mengecek Menampilkan
Jumlah Input PIN Menu Utama

Lebih dari 3x?

ya

Memblokir
Account
Selesai

79
 2. Activity Diagram: Mengecek Saldo
act 3 AD Mengecek Saldo

Nasabah Sistem ATM Sistem Core Banking

Mulai

Memilih Mengecek Merequest Memproses request

Saldo di Menu Utama Jumlah Saldo j umlah saldo

Menampilkan Jumlah
Saldo di Layar

Selesai

80
2. Activity Diagram: Mentransfer Uang
act 5 AD Mentransfer Uang

Nasabah Sistem ATM Sistem Core Banking

Mulai

Memilih Mentransfer Menampilkan Isian No

Uang di Menu Utama Rekening Tuj uan

Mengisikan No Merequest Validasi Memv alidasi No

Rekening Tuj uan Account Rekening Tuj uan
tidak
Rekening Valid?

ya
Mengisikan Menampilkan Isian
Jumlah Uang Jumlah Uang

tidak

Merequest Mengecek
Kecukupan Saldo Kecukupan Saldo

Saldo Cukup?

ya
Memproses
Pengiriman Uang

Selesai

81
2. Activity Diagram: Melakukan Logout
act 6 AD Melakukan Logout

Nasabah Sistem ATM

Mulai

Memilih Memproses
Logout Logout

Mengeluarkan Kartu
di Kotak Kartu

Mengeluarkan Kuitansi
di Kotak Kuitansi

Selesai

82
Latihan Studi Kasus
• Pahami kembali System Request yang sudah
dibuat
• Lanjutkan dengan membuat Activity Diagram
dari System Request yang dibuat

83
Sequence Diagram

84
Sequence Diagrams
• Illustrate the objects that participate in
a use case
• Show the messages that pass between
objects for a particular use-case over
time

85
Sequence Diagram Syntax
AN ACTOR

AN OBJECT
anObject:aClass

A LIFELINE

A FOCUS OF CONTROL

A MESSAGE aMessage()

OBJECT DESTRUCTION x

86
 3. Sequence Diagram: Memasukkan PIN
sd 1 SD Memasukan PIN

Nasabah
MenuPIN PengelolaValidasi Login MenuUtama

masukanPIN()

validasiPIN()

getPIN()

alt PIN Valid?

tampilkan()
[ya]

[tidak]

alt lebih dari3x?

[tidak] tampilkan()

[ya]
blokirAccount()
errorAccountDiblokir()

87
Type of Class
1. Boundary Class
• Class yang berhubungan dengan actor (user interface)

2. Control Class
• Class yang berhubungan dengan pemrosesan, komputasi,
penghitungan, dsb

3. Entity Class
• Class yang berhubungan dengan data (flat file or
database)

88
 3. Sequence Diagram: Mengecek Saldo
sd 2 SD Mengecek Saldo

Nasabah Sistem Core Banking

MenuUtama PengelolaPengecekanSaldo Balance Transaction MenuMengecekSaldo

pilihMengecekSaldo()

cekSaldo(id)

requestCekSaldo(id)

setSaldo(saldo)

setTransaksi(id, date, type)

tampilkanSaldo()

89
 3. Sequence Diagram: Mentransfer Uang
sd 4 SD Mengirim Uang

Nasabah
MenuUtama MenuMengirimUang PengelolaPengirimanUang Pengirim:Balance Penerima:Balance Transaction Account

pilihMengirimUang()
tampilkan()

masukanJumlahUang()

cekKecukupanSaldo()

getSaldo()

tampilkanHasil()

masukanAccountTujuan()
validasiAccount()
getID()

alt Account Valid?

tampilkan()
[tidak]

[ya]
kirimUang(idPengirim, idPenerima, jumlah)

setSaldo(saldo)

setSaldo(saldo)

setTransaksi(id, date, type)

90
3. Sequence Diagram: Melakukan Logout
sd 5 SD Melakukan Logout

Nasabah
MenuUtama PengelolaLogout MenuLogout

pilihLogout()

logout()

tampilkan()

91
Latihan Studi Kasus
• Pahami kembali System Request yang sudah
dibuat
• Lanjutkan dengan membuat Sequence
Diagram dari System Request yang dibuat

92
Class Diagram

93
Class Diagram Elements
1. Classes
2. Attributes
3. Operations
4. Relationships

94
Classes
• Templates for creating instances or
objects
• All objects of a class have same structure
and behavior, but contain different
attributes
1. Concrete: used to create actual objects
2. Abstract: extended to create other classes

95
Attributes
• Units of information relevant to the
description of the class
• Only attributes important to the task should
be included
• Attributes should be primitive types (integers,
strings, doubles, date, time, Boolean, etc.)

96
Operations (Methods)
• Defines the behavior of the class
• Action that instances/objects can take
• Focus on relevant problem-specific
operations (at this point)

97
Relationships
• Generalization
• “Is-A” relationship
• Enables inheritance of attributes & oper's
• Subclasses and superclasses
• Principle of substitutability
• Subclass be substituted for superclass
• Aggregation
• “Has-A” relationship
• Relates parts to wholes
• Uses decomposition
• Association
• Relationships that don't fit “Is-A” or “Has-A”
• Often a weaker form of “Has-A”
• Miscellaneous relationships between classes
• Example:
• Patient schedules an appointment
• So the appointment has a patient
98
Example Class Diagram

99
More on Attributes
• Derived attributes
• /age, for example can be calculated from birth
date and current date
• Visibility of attributes
• +Public: not hidden from any object
• #Protected: hidden from all but immediate
subclasses
• –Private: hidden from all other classes
• Default is private

100
Relationship Multiplicity
Exactly one
Dept 1 Boss

Zero or more
Employee 0..* Child

One or more
Boss 1..* Employee

Zero or one
Employee 0..1 Spouse

Specified
range Employee 2..4 Vacation

Disjoint
Employee 1..3, 5 Committee
ranges

101
Class

102
Class with Attribute and Method

103
Class Association

104
Multiplicity

105
Inheritance

106
Interface

107
 Class Diagram – Case Study
class CD Sistem ATM

PengelolaValidasi Login
access
+ blokirAccount(): void
+ validasiKartu() Balance
+ validasiPIN(): void
do
access
MenuMengecekSaldo PengelolaPengecekanSaldo
MenuPIN
do

access

is-a
has-a
Transaction

MenuUtama MenuMengirimUang PengelolaPengirimanUang

SistemATM is-a do

access
is-a Account

~ alamat: String
~ id: int
~ nama: String
MenuLogout PengelolaLogout ~ pekerjaan: String
do
+ getAlamat(): String
+ getId(): int
+ getNama(): String
+ getPekerjaan(): String
+ setAlamat(String): void
+ setId(int): void
+ setNama(String): void
+ setPekerjaan(String): void

108
Latihan Studi Kasus
• Pahami kembali System Request yang sudah
dibuat
• Lanjutkan dengan membuat Class Diagram
dari System Request yang dibuat

109
 Deployment Diagram – Case Study
deployment DD Sistem ATM

Application Serv er

Rich Client Web Container EJB Container DBMS

«artifact»
JSP
«artifact» «artifact»
MySQL
JFC «artifact»
SessionBean
«artifact»
JSF

«artifact» «artifact»
JVM Zend Optimizer
«artifact»
Serv let

110
User Interface Design – Case Study

111
Data Model – Case Study
class DM Sistem ATM

Account

«column»
*PK id: INTEGER
nama: VARCHAR(50)
jeniskelamin: VARCHAR(50)
pekerjaan: VARCHAR(50)
+idLogin FK idLogin: INTEGER +idBalance
FK idBalance: INTEGER
FK idTransaction: INTEGER

«FK»
+ FK_idBalance(INTEGER)
+ FK_idLogin(INTEGER)
+ FK_idTransaction(INTEGER)
«PK»
+ PK_Account(INTEGER)

+idTransaction

+PK_Transaction

+PK_Login Transaction +PK_Balance

Login «column» Balance

*PK idTransaction: INTEGER
«column» tanggal: DATE «column»
*PK idLogin: INTEGER tipe: INTEGER *PK idBalance: INTEGER
pin: INTEGER transaksi: VARCHAR(50) saldo: INTEGER

«PK» «PK» «PK»

+ PK_Login(INTEGER) + PK_Transaction(INTEGER) + PK_Balance(INTEGER)

112
Latihan Studi Kasus
• Pahami kembali System Request yang sudah
dibuat
• Lanjutkan dengan membuat Deployment
Diagram, User Interface Design dan Data
Model dari System Request yang dibuat

113
2.1.3 Implementation

1. Construction
2. Testing
3. Documentation
4. Installation

114
1. Construction
• Assigning the programmers
• Coordinating the activities
• Managing the schedule

115
Assigning Programmers
• Start by looking at the package diagrams
• Assign similar modules to the same programmer
• Remember the "programmer paradox"
• Can't just add more people
• Fewer programmers is normally better
• Adding manpower to a late project makes it
later (Brook, 1975)
• “Just because a woman can make a baby in nine
months, it does not follow that nine women can
make a baby in one month”

116
Coordinating Activities
• Hold weekly project meetings
• discuss changes to the system
• discuss other issues of the past week
• Create and follow standards
• Set up separate workspace for
• development, testing, production
• as a minimum, separate files
• Use change control
• program log, sign-in/-out
• Use CASE tools

117
Managing the Schedule
• Use initial time estimates as a baseline
• Revise time estimates as construction proceeds
• Fight against scope creep
• Monitor “minor” slippage
• Create risk assessment and track changing risks
• Risks change as deadline approaches
• Fight the temptation to lower quality to meet
unreasonable schedule demands

118
Anekdot di Pengembangan
Software
• Project Manager is a Person who thinks nine women can
deliver a baby in One month
• Developer is a Person who thinks it will take 18 months
to deliver a Baby
• Client is the one who doesn't know why he wants a baby
• Marketing Manager is a person who thinks he can deliver
a baby even if no man and woman are available
• Tester is a person who always tells his wife that this is not
the Right baby
• Human Resource is a person who thinks that a donkey
can deliver a human baby if given 9 months

119
Program Code – Case Study

120
2. Testing
• Testing can never prove there are no errors
• The purpose is not to demonstrate that the system
is free of errors
• The purpose is to detect as many errors as possible
• It is dangerous to test early modules without an
overall testing plan
• It may be difficult to reproduce sequence of events
causing an error
• Testing must be done systematically and results
documented carefully

121
Stage of Testing
1. Unit testing
• Tests each module to assure that it performs its
function
2. Integration testing
• Tests the interaction of modules to assure that they
work together
3. System testing
• Tests to assure that the software works well as part
of the overall system
4. Acceptance testing
• Tests to assure that the system serves organizational
needs
122
Error Discover Rates

123
3. Documentation
1. System Documentation
2. User Documentation

124
System Documentation
• Compiled and refined System Specification
• Helps programmers and analysts understand
the application
• Used for development and maintenance
• Largely a by product of the SDLC phases
• Often can be automated (JavaDoc)

125
User Documentation
• Help users operate the system
• High quality documentation takes about 3 hours per
page to produce
• Should not be left to the end of the project
• User Documentation Type:
• Reference documents (help system)
• User needs to learn a specific task
• Procedures manuals
• How to perform a business function
• May require several tasks
• Tutorials
• How to use major function of system

126
4. Installation
• Transitioning to new systems involves
managing change from pre-existing
norms and habits
• Change management involves:
1. Unfreezing -- loosening up peoples’ habits and
norms
2. Moving – conversion from old to new systems
3. Refreezing -- institutionalize and make efficient
the new way of doing things

127
Unfreezing
• Activities to date facilitate unfreezing
• Users:
• Already know of the new system
• Helped in the analysis phase
• Helped in the design
• This probably has already unfreezed
current habits and norms

128
Conversion Strategy

129
Types of System Adopters
• Ready Adopters (20% - 30%)
• Recognize the benefits
• Quickly adopt the system
• Become proponents of the system

• Resistant adopters (20% - 30%)

• Refuse to accept the change
• Fight against the system

• Reluctant Adopters (40% - 60%)

• Apathetic & blow with the wind
130
 SDLC and Artifacts
1. Planning System
1.1 System Request
1.2 Feasibility Analysis
Proposal
2. Analysis
2.1 Use Case Diagram
2.2 Activity Diagram
2.3 Sequence Diagram System
3. Design Specification
3.1 Class Diagram
3.2 Deployment Diagram
3.3 User Interface Design
3.4 Data Model
New
4. Implementation
4.1 Program Code
Software
4.2 Testing Plan
4.3 Documentation 131
2.2 Software Effort Estimation

132
 “Size” of Software Systems

Source: Wikipedia

133
“Size” of Software Systems

Caper Jones, The Economic of

Software Quality (2012)

134
 Software Effort Estimation
Methods

1. Simply Method 2. Function Point 3. Use Case Point

(Industry Std Percentages) (Allen Albrecht, 1979) (Gustav Karner, 1993)

• Use the time spent for • Estimate System Size • Estimate System Size (Use
planning (Function Point) Case Points)
• Along with industry • Estimate Effort Required • Estimate Effort Required
standard percentages (Person-Month) (Person-Month)
• Estimate the overall time • Estimate Time Required • Estimate Time Required
for the project (Month) (Month)

135
1. Simply Method

136
Simply Method

137
Time Spent for Each Phase
We are given that
Planning time  0.15  Overall time
so
Planning time
Overall time 
0.15

Planning time
Analysis time  0.2 
0.15
138
Estimate the Overall Time

Planning Analysis Design Implementation

Industry
Standard
For Web 15% 20% 35% 30%
Applications

Effort
Required 4 5.33 9.33 8
in Time (month)

4
Example: Analysis 0.2   5month
.33
0.15

139
2. Function Point

140
Function Point Approach

(Allen Albrecht, 1979)

141
A. Function Points Estimation
-- Step One (TUFP)

Complexity

Description Low Medium High Total

Inputs __x 3 __x 4 __x 6 ____

Outputs __x 4 __x 5 __x 7 ____

Queries __x 3 __x 4 __x 6 ____

Files __x 7 __x 10 __x 15 ____

Program __x 5 __x 7 __x 10 ____

Interfaces

TOTAL UNADJUSTED FUNCTION POINTS ____

142
Example: Sistem ATM

143
Function Points Estimation
-- Step Two (Processing Complexity)
Scale of 0 to 3

Data Communications _____

Heavy Use Configuration _____
Transaction Rate _____
End-User efficiency _____
Complex Processing _____
Installation Ease _____
Multiple sites _____
Performance _____
Distributed functions _____
On-line data entry _____
On-line update _____
Reusability _____
Operational Ease _____
Extensibility _____

Processing Complexity (PC) _____

144
Example: Sistem ATM

145
Function Point Estimation
-- Step Three (TAFP)
Processing Complexity (PC) = 7
(From Step Two)

Adjusted Processing
Complexity (PCA) = 0.65 + (0.01 * 7 ) = 0.72
Total Adjusted
Function Points (TAFP): 338 * 0.72 = 243
(From Step One)

146
Adjusted Processing Complexity

Choose standard Adjusted Project

Complexity (PCA) from the range:
1. 0.65 Simple systems
2. 1.0 "Normal" systems
3. 1.35 Complex systems

147
Converting Function Points to Lines of
Code

Language LOC/Function Code Point

C 130
COBOL 110
JAVA 55
C++ 50
Turbo Pascal 50
Visual Basic 30
PowerBuilder 15
HTML 15
Packages 10-40
(e.g., Access, Excel)

Source: Capers Jones, Software Productivity Research

148
Lines of Codes (LOC)

Line of Codes (LOC) = TAFP * LOC/TAFP

Example:

If TAFP = 243 Then we build the software using Java

LOC = (243 * 55) = 13365 line of codes

149
Contoh Jenis Aplikasi dan FP

Caper Jones, The Economic of

Software Quality (2012)

150
B. Estimating Effort
Effort = 1.4 * thousands-of- lines-of-code
(in Person- Months)

Example:

If LOC = 13365 Then...

Effort = (1.4 * 13.365) = 18.711 Person Months

151
C. Estimating Time
Time = 3.0 * person-months1/3
(in Months)

Example:

If LOC = 13365 Then...

Effort = (1.4 * 13.365) = 18.711 person-months
Time = 3.0 * 18.711 1/3 = 7.9 month

152
Calculate System Size
Imagine that job hunting has been going so well that
you need to develop a system to support your efforts.
The system should allow you to input information
about the companies with which you interview, the
interviews and office visits that you have scheduled,
and the offers that you receive. It should be able to
produce reports, such as a company contact list, an
interview schedule, and an office visit schedule, as well
as produce thank-you letters to be brought into a word
processor to customize. You also need the system to
answer queries, such as the number of interviews by
city and your average offer amount. The system will be
developed using Java.
153
Hitung Size dari Sistem dengan
Function Point
• Sebuah perusahaan membutuhkan sistem job seeker untuk pencari kerja
dan perusahaan pembuka lowongan pekerjaan
• Sistem memungkinkan pencari kerja untuk menginput data curriculum
vitae. Di sisi lain, perusahan pembuka lowongan kerja bisa menginput data
perusahaan dan lowongan pekerjaan yang disediakan
• Pencari kerja dapat melakukan pencarian (query) tentang lowongan
pekerjaan apa saja yang tersedia, sedangkan pembuka lowongan kerja
mencari tentang siapa saja yang sudah mendaftar di suatu lowongan
pekerjaan
• Sistem mampu memproduksi laporan dan statistik lengkap tentang pencari
kerja, perusahaan, jenis lowongan pekerjaan dan tren lowongan kerja yang
sedang populer
• Laporan statistik akan disajikan dalam bentuk infografik dan juga tersedia
dalam bentuk file pdf yang bisa didownload
• Sistem akan dikembangkan dengan menggunakan bahasa pemrograman
Java
154
TUFP
Fungsi Bobot Total
Input 4 3 12
Output 3 4 12
Queries 2 3 6
File 1 7 7
Program 5 5 25
Interface
TUFP 62

155
TAFP
Processing Complexity (PC) = 6
(From Step Two)

Adjusted Processing
Complexity (PCA) = 0.65 + (0.01 * 6 ) = 0.71
Total Adjusted
Function Points (TAFP): 62 * 0.71 = 44.02
(From Step One)

156
LOC  Effort (ManMonth) Time
(Month)
• LOC = 55*44.02 = 2421

• Effort = 1.4*2.421 = 3.39 MM

• Time = 3.0 * 3.39 (1/3) = 4.5 M

157
3. Use Case Point

158
 Use Case Points
Unadjusted Actor Weighting (UAW)
Actor Type Description Weighting Factor
Simple External System with well-defined API 1
Average External System using a protocol- 2
based
interface, e.g., HTTP, TCT/IP, SQL
Complex Human 3

Unadjusted Use Case Weighting (UUCW)

Use-Case Type Description Weighting Factor
Simple 1-3 transactions 5
Average 4-7 transactions 10
Complex More than 7 transactions 15

Unadjusted Use Case Points (UUCP) = UAW + UUCW

159
 Sistem AT M Sistem AT M

Sistem ATM – Use Case Diagram

uc UCD - Sistem ATM
Memasukkan Kartu Memasukkan PIN
Memasukkan Kartu
«include» «include»
Memasukkan PIN

Sistem ATM
Sistem ATM

Memasukkan Kartu Memasukkan PIN

Human = 3
Memasukkan KartuMengecek Saldo
«include»
Memasukkan PIN
Mengecek Saldo
«include»

Transaction = ?
Pengguna
Mentransfer Uang Mengecek Saldo Uang
Mentransfer
Mengecek Saldo

Pengguna
Mentransfer Uang
Mentransfer
Melakukan LogoutUang Melakukan
MengambilLogout
Uang Mengambil Uang

Melakukan Logout Mengambil Uang

ukan Logout Mengambil Uang

160
 Sequence Diagram - Mentransfer Uang
sd SD4 - Mentransfer Uang

Pengguna MenuUtama MenuMentransferUang ProsesMentransferUang Account pengirim:Balance penerima:Balance T ransaksi

memilihMentransferUang()

tampilkan()

memasukkanJumlahUang() Transaction = 3
memasukkanAccountT ujuan()

transferUang(id, jumlah)

getIDBalance()

getSaldo()

alt saldo cukup?

setSaldo(saldo)
[ya]
setSaldo(saldo)

setT ransaksi(tgl, jenis)

tampilkanUangBerhasilDikirim()

[tidak]
tampilkanErrorSaldoT idakCukup()

161
Technical Complexity Factors
(TCF)
Factor Description Weight
Number
T1 Distributed system 2.0
T2 Response time or throughput performance 1.0
objectives
T3 End-user online efficiency 1.0
T4 Complex internal processing 1.0
T5 Reusability of code 1.0
T6 Easy to install 0.5
T7 Ease of use 0.5
T8 Portability 2.0
T9 Ease of change 1.0

TCF = 0.6 + (0.01 * TFactor)

162
Environmental Complexity Factors
(ECF)
Factor Description Weight
Number
E1 Familiarity with system development process in use 1.5
E2 Application experience 0.5
E3 Object-oriented experience 1.0
E4 Lead analyst capability 0.5
E5 Motivation 1.0
E6 Requirements stability 2.0
E7 Part time staff -1.0
E8 Difficulty of programming language -1.0

ECF = 1.4 + (-0.03 * EFactor)

163
Computing Use Case Points

• Adjusted Use Case Points (UCP) = UUCP * TCF * ECF

• Effort in Person Hours = UCP * PHM

164
 Person Hour Multiplier (PHM)
Let F1 = Number of ECF1 to ECF6 that are < 3
Let F2 = Number of ECF7 and ECF8 that are > 3

If F1 + F2 <= 2
PHM = 20
Else if F1 + F2 = 3 or 4
PHM = 28
Else
Scrap the project

165
Use Case Points in Sparx EA

166
Example: Sistem ATM
UCP = 19
PHM = 20
PH = 20*19 = 360
PM = 360/8/22 = 2.05

TIME (M) = 3.0 * PM 1/3

TIME (M) = 3.0 * 2.05 1/3
TIME (M) = 3 * 1.27 = 3.81

167
Example: Sistem ATM
UCP = 23
PHM = 20
PH = 20*23 = 460
PM = 460/8/22 = 2.61

TIME (M) = 3.0 * PM 1/3

TIME (M) = 3.0 * 2.61 1/3
TIME (M) = 4.13

168
Reference (Foundation)
• Ian Sommerville, Software Engineering 10th Edition,
Addison-Wesley, 2015
• Roger S. Pressman, Software Engineering: A Practitioner’s
Approach 8th Edition, McGraw-Hill, 2014
• P. Bourque and R.E. Fairley, eds., Guide to the Software
Engineering Body of Knowledge Version 3.0, IEEE Computer
Society, 2014
• Albert Endres dan Dieter Rombach, A Handbook of Software
and Systems Engineering, Pearson Education Limited, 2003
• Yingxu Wang, Software Engineering Foundations: A
Software Science Perspective, Auerbach Publications, Taylor
& Francis Group, 2008
Reference (Process)
• Alan Dennis et al, Systems Analysis and Design with UML –
4th Edition, John Wiley and Sons, 2012
• Dan Pilone and Russ Miles, Head First Software
Development, O’Reilly Media, 2008
• Barclay and Savage, Object-Oriented Design with UML and
Java, Elsevier, 2004
• Kenneth E. Kendall and Julie E Kendall, Systems Analysis and
Design 8th Edition, Prentice Hall, 2010
• Hassan Gomaa, Software Modeling and Design: UML, Use
Cases, Patterns, and Software Architectures, Cambridge
University Press, 2011
• Layna Fischer (edt.), BPMN 2.0 Handbook Second Edition,
Future Strategies, 2012
Reference (Quality)
• Daniel Galin, Software Quality Assurance, Addison-
Wesley, 2004
• Kshirasagar Naik and Priyadarshi Tripathy, Software
Testing and Quality Assurance, John Wiley & Sons,
Inc., 2008
• Jeff Tian, Software Quality Engineering, John Wiley
& Sons, Inc., 2005
• G. Gordon Schulmeyer, Handbook of Software
Quality Assurance Fourth Edition, Artech House,
2008
Reference (Research)
• Christian W. Dawson, Project in Computing and Information
System a Student Guide 2nd Edition, Addison-Wesley, 2009
• Mikael Berndtsson, Jörgen Hansson, Björn Olsson, Björn
Lundell, Thesis Projects - A Guide for Students in Computer
Science and Information System 2nd Edition, Springer-Verlag
London Limited, 2008
• Mary Shaw, Writing Good Software Engineering Research
Papers, Proceedings of the 25th International Conference on
Software Engineering, 2003
• C. Wohlin, P. Runeson, M. Host, M. C. Ohlsson, B. Regnell, and
A. Wesslen, Experimentation in Software Engineering, Springer,
2012
• P. Runeson, M. Host, A. Rainer, and B. Regnell, Case Study
Research in Software Engineering: Guiidelines and Examples,
John Wiley & Sons, Inc., 2012
172