Systems Analysis

and Design
Dr. Ir. Sumijan, M.Sc
[email protected]
[email protected]

1
Learning Design
Pretest dan Posttest untuk
Mengukur Kompetensi Kognifif

Penyajian Materi dengan

Penugasan berbasis Self-
Model Minimalism berbasis
Contained Project dan
Konsep Amati-Tiru-
Literatur Review
Modifikasi

Latihan Secara Iteratif untuk

Meningkatkan Kompetensi
Kognitif dan Psikomotorik
2
Textbook

3
References
1. Alan Dennis et al, Systems Analysis and Design with UML 4t
h Edition, John Wiley and Sons, 2013

2. Kenneth E. Kendall and Julie E Kendall, Systems Analysis and

Design 8th Edition, Prentice Hall, 2010
3. Hassan Gomaa, Software Modeling and Design: UML, Use C
ases, Patterns, and Software Architectures, Cambridge Univ
ersity Press, 2011
4. Gary B. Shelly and Harry J. Rosenblatt, Systems Analysis and
Design 9th Edition, Course Technology, 2011
5. Howard Podeswa, UML for the IT Business Analyst 2nd Editio
n, Course Technology, 2009
6. Jeffrey A. Hoffer et al, Modern Systems Analysis and Design
6th Edition, Prentice Hall, 2010
4
 Pre-Test
1. Sebutkan tahapan pengembangan sistem atau system development lif
e cycle (SDLC)!
2. Sebutkan beberapa metodologi pengembangan sistem yang anda keta
hui!
3. Gambarkan requirement di bawah dengan use case diagram!
SISTEM ELIBRARY
• Sistem elibrary memungkinkan pengguna untuk melakukan registrasi
dan login
• Setelah menjadi member, pengguna dapat memodifikasi profile, serta
mencari dan mendownload koleksi buku di sistem elibrary
• Admin sistem elibrary melakukan approval terhadap registrasi dan
menampilkan laporan aktifitas pengguna secara individual maupun total

4. Gambarkan activity diagram, sequence diagram dan class diagram dar

i requirement di atas!
5. Hitung dengan metode yang anda ketahui, berapa orang dan waktu (b
ulan) yang dibutuhkan untuk mengembangkan sistem di atas!
5
Course Outline

1. Introduction

2. Project Planning

3. System Analysis

4. System Design

5. System Implementation

6
1. Introduction
1.1 Why We Learn Systems Analysis and Design
1.2 Systems Analyst and Its Roles
1.3 Systems Development Life Cycle
1.4 Systems Development Methodology
1.5 Methodology Selection Strategy
7
1.1 Why We Learn Systems Anal
ysis and Design

8
Systems Development Projects
Fail
• More than half of all systems development proj
ects Fail
(42% - Standish Group, 53% - General Accounting Office)
• Canceled before completion
• System is never used once finished
• Doesn't provide the expected benefits

• Most of the ones that don't fail:

• Are delivered late
• Are over budget
• Don't provide the features promised
9
 Recent Significant IT Failures
Company Year Outcome
Hudson Bay (Canada) 2005 Inventory system problems lead to $33.3
million loss
UK Inland Revenue 2004/5 $3.45 billion tax-credit overpayment caused
by software errors
Avis Europe PLC (UK) 2004 Enterprise resource planning (ERP) system
cancelled after $54.5 million spent

Ford Motor Co. 2004 Purchasing system abandoned after

deployment costing approximately $400 M

Hewlett-Packard Co. 2004 ERP system problems contribute to $160

million loss
AT&T Wireless 2004 Customer relations management (CRM)
system upgrade problems lead to $100M loss

10
 Keunikan dari Software
Karakteristik Software Hardware
Kompleksitas Tingkat kompleksitas Tingkat kompleksitas
dari produk software produk lain rendah,
tinggi, dengan dengan kemungkinan
kemungkinan perubahan perubahan parameter
parameter dan fungsi dan fungsi tidak
yang sangat beragam beragam
Visibilitas Produk tidak terlihat Produk terlihat dengan
Produk dengan kasat mata, kasat mata, termasuk
termasuk bila ada cacat bila ada cacat (defect)
(defect) dari produk dari produk

11
Software Errors, Faults, Failures

12
Analisis Kasus
• Suatu perusahaan PT ABC memproduksi software yang akan di
tanam ke dalam suatu device
• Salah satu fungsi yang terdapat pada software adalah akan me
matikan device secara otomatis apabila suhu ruangan lebih bes
ar daripada 30o celcius
• Programmer salah menuliskan logika menjadi:
…
if (suhu > 3) shutdownDevice();
…
• Error ini tidak pernah menyebabkan failure pada software, dan
perusahaan PT ABC sampai saat ini terkenal sebagai perusahaa
n yang memproduksi software tanpa bug
• Jelaskan mengapa bisa terjadi demikian!
13
Warranty Lawsuits
• Mortenson vs. Timeberline Software (TS) (≈1993)
• Mortenson menggunakan software yang diproduksi TS untuk me
mbuka tender pembangunan rumah sakit
• Software memiliki bug sehingga memenangkan perusahaan yang
mengajukan proposal paling mahal (kerugian 2 miliar USD)
• TS tahu tentang bug itu, tapi tidak mengirimkan update ke Morte
nson
• Pengadilan di Amerika Serikat memenangkan perusahaan TS

• Uniform Computer Information Transaction Act (UCIT

A) allows software manufacturers to:
• disclaim all liability for defects
• prevent the transfer of software from person to person
14
Disclaimer of Warranties
DISCLAIMER OF WARRANTIES. TO THE MAXIMUM EXTENT PERMIT
TED BY APPLICABLE LAW, MICROSOFT AND ITS SUPPLIERS PROVIDE
TO YOU THE SOFTWARE COMPONENT, AND ANY (IF ANY) SUPPORT
SERVICES RELATED TO THE SOFTWARE COMPONENT ("SUPPORT SE
RVICES") AS IS AND WITH ALL FAULTS; AND MICROSOFT AND ITS S
UPPLIERS HEREBY DISCLAIM WITH RESPECT TO THE SOFTWARE CO
MPONENT AND SUPPORT SERVICES ALL WARRANTIES AND CONDIT
IONS, WHETHER EXPRESS, IMPLIED OR STATUTORY, INCLUDING, BU
T NOT LIMITED TO, ANY (IF ANY) WARRANTIES OR CONDITIONS OF
OR RELATED TO: TITLE, NON-INFRINGEMENT, MERCHANTABILITY, F
ITNESS FOR A PARTICULAR PURPOSE, LACK OF VIRUSES, ACCURACY
OR COMPLETENESS OF RESPONSES, RESULTS, LACK OF NEGLIGENC
E OR LACK OF WORKMANLIKE EFFORT, QUIET ENJOYMENT, QUIET
POSSESSION, AND CORRESPONDENCE TO DESCRIPTION. THE ENTI
RE RISK ARISING OUT OF USE OR PERFORMANCE OF THE SOFTW
ARE COMPONENT AND ANY SUPPORT SERVICES REMAINS WITH
YOU.
15
16
Is it Possible?

17
 Sofware Quality?
• Software quality is (IEEE, 1991):
1. The degree to which a syste
m, component, or process m
eets specified requirements
2. The degree to which a syste
m, component, or process m
eets customer or user needs
or expectations

• Quality means conformance t

o requirements (Crosby, 1979)

18
1.2 Systems Analyst and Its Role
s

19
Analyst Related Role
1. Business analyst
2. System analyst
3. Infrastructure analyst
4. Change management analyst
5. Project manager

20
 Role in System Development

Project Manager

Business System
Programmer Tester
Analyst Analyst

21
Business Analyst
• Focuses on business issues surrounding t
he system
• The business value of the system
• Improvements in business processes
• New business processes needed with new system

• Requires business skills and professional

training

22
System Analyst
• The systems analyst is a key person analyzing the
business, identifying opportunities for improvem
ent, and designing information systems to imple
ment these ideas
• Focuses on Information System (IS) Issues
• How IS can improve business processes
• Designs new information system
• Ensures IS quality standards are maintained
• Requires training & experience in design analysis,
programming, business (to lesser degree)

23
Infrastructure Analyst
• Focuses on interfaces between new syste
m & existing infrastructure
• Makes sure new system follows organizational stand
ards
• Identifies required infrastructure changes
• Requires experience in network & databas
e administration
• Requires knowledge of hardware systems

24
Change Management Analyst
• Focuses on system installation
• Documentation & support for users
• Coordinate training of users
• Strategies to overcome resistance
• Requires experience in organizational b
ehavior
• Requires experience in change manage
ment

25
Project Manager
• Responsible for schedule and budget
• Ensures promised benefits are delivered
• Manages team members
• Responsible for project plan and reportin
g progress
• Requires project management experienc
e

26
27
1.3 Systems Development Life C
ycle

28
Systems Development Life Cycle (SDLC)

Planning

Implementation Analysis

Design

29
Project Phases
1. Planning: Why build the system?
• System request, feasibility analysis, project size estimatio
n
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 install
ation

30
Planning
1. Identifying business value (System Request)
• Lower costs
• Increase profits

2. Analyze feasibility
• Technical Feasibility
• Economic Feasibility
• Organizational Feasibility

(System Proposal)
31
Analysis
1. Requirement gathering by answering the que
stions:
• Who will use the system?
• What will the system do?
• When will it be used?
2. Investigate the current system
3. Identify possible improvements
4. Develop a concept for new system

(System Specification)
32
Design
1. Program Design (UML Diagrams)
• What programs need to be written
• Exactly what each program will do
2. User Interface Design
• How users interact with system
• Forms / reports used by the system
3. Data Design (ER Diagrams)
• What data is to be stored
• What format the data will be in
• Where the data will be stored

(System Specification)
33
Implementation
1. Construction
• New system is built and tested
• Often testing is the longest part
2. Testing
• Unit Testing
• Integration Testing
• System Testing
• User Acceptance Test
3. Installation
• Old system is turned off
• New system is turned on

34
Processes and Deliverables
Process Product

Planning System Proposal

Analysis System Specification

Design

Implementation New System with

Testing/Maintenance Plan
35
SDLC and Deliverables
Planning
(System Proposal)

Implementation Analysis
(New System) (System Specification)

Design
(System Specification)

36
1.4 Systems Development Meth
odology (Model Process)

37
Software Development Method
ology (Model Process)
• A formalized approach to implementing the Softwar
e Development Life Cycle (SDLC) (Dennis, 2012)

• A simplified representation of a software process (So

mmerville, 2015)

• A distinct set of activities, actions, tasks, milestones,

and work products required to engineer high quality
software (Pressman, 2015)

38
Major Methodologies
1. Structured Design
• Waterfall method More
Prescriptive
• Parallel development
2. Rapid Application Development
• Phased Development
• Prototyping
• Throw-away Prototyping More
Adaptive
3. Agile Development
• Extreme Programming (XP)
• Scrum
• Lean Development
(Dennis, 2012)
39
Methodology Timeline

40
Activities and Artifacts Compariso
n

41
1.4.1 Structured Design

42
Structured Design
• Projects move methodically from one to the
next step
• Generally, a step is finished before the next o
ne begins

• Type of Structured Desin:

1. Waterfall Method
2. Parallel Development

43
 Waterfall Method

Pros Cons
Identifies systems Design must be specified on
requirements long paper before programming
before programming begins
Begins, it minimizes Long time between system
change to the proposal and delivery of new
requirements as the system
project proceed (mature)
Rework is very hard

44
 Parallel Development

Addresses problem of time

gap between proposal and
delivery:
• Breaks project into parallel
subproject
• Integrates them at the end

45
1.4.2 Rapid Application Developme
nt

46
Rapid Application Development (R
AD)
• Type of RAD:
1. Phased development: a series of versions
2. Prototyping: System prototyping
3. Throw-away prototyping: design prototyping

• Critical elements to speed up the SDLC:

• CASE tools
• Visual programming languages
• Code generators
47
 RAD: Phased Development

Pros Cons
Gets useful system to Initial system is intentionally
users quickly incomplete
Most important System requirements expand
functions tested most as users see versions
48
RAD: Prototyping
• Analysis, Design, Implementation are
performed concurrently
• Start with a "quick-and-dirty" prototype,
Provides minimal functionality
• Repeat process, refining the prototype
each time
• Stop when prototype is a working system

49
RAD: Throw-Away Prototypin
g • Use prototypes only to understand requirements
• Example: use html to show UI
• Prototype is not a working design
• Once requirements are understood, the
prototypes are thrown away

50
1.4.3 Agile Development

51
3. Agile Development
• Just a few rules that are easy to learn and follow
• Streamline the SDLC
• Eliminate much of the modeling and documentation
• Emphasize simple, iterative application development

• Type of Agile Development:

1. Extreme Programming (XP) (Kent Beck)
2. Scrum (Ken Schwaber and Jeff Sutherland)
3. Lean Development (Mary Poppendieck and Tom Poppendieck)
4. Dynamic Systems Development Model (DSDM) (Dane Faulkner)

52
Extreme Programming (XP)

53
 • Project members form a Scrum Team consisting of
Scrum 5–9 people
• The goal of the Sprint is determined and the
prioritized functionality is broken down into
detailed tasks
• The team is self-organized and the members have
a joint responsibility for the results
• Each Sprint enhances the product’s market value
and adds new functions and improvements that
can be delivered to the customer

54
Scrum

55
Iterative Scrum
Scrum

57
Scrum

58
Boards

59
60
XP vs Scrum vs Lean
• XP deals with how to work with programmin
g
• Scrum deals with how the project is organize
d and planned
• Lean Development deals with which compre
hensive principles should apply for the entire
development organization

61
62
1.5 Methodology Selection Strat
egy

63
Selection Factors

1. Clarity of User Requirements

2. Familiarity with Technology
3. System Complexity
4. System Reliability
5. Short Time Schedules
6. Schedule Visibility

64
Selection Factors

65
Latihan Analisis Kasus:
Memilih Metodologi yang Tepat
• Seandainya, anda adalah seorang software engineer di perusahaan
PT BlackSoft, sebuah perusahaan IT yang memiliki kantor cabang di
berbagai tempat di dunia
• PT BlackSoft ingin membangun sebuah sistem yang bisa menampilk
an informasi tentang sumber daya manusia yang dimiliki, baik itu lok
asi saat ini, latar belakang pendidikan, jadwal pekerjaan dan pengala
man kerja yang dimiliki
• Asumsikan bahwa ini adalah ide baru yang belum pernah diimpleme
ntasikan di PT BlackSoft sebelumnya
• PT BlackSoft memiliki jaringan internasional dimana kantor cabang d
i berbagai negara menggunakan hardware dan software yang berbe
da
• Manajemen ingin agar sistem dapat selesai dikerjakan dan mulai bis
a berjalan dalam satu tahun
66
Summary -1-
• The systems analyst is a key person analyzing
the business, identifying opportunities for imp
rovement, and designing information systems
to implement these ideas
• There are five major team roles:
1. Business analyst
2. Systems analyst
3. Infrastructure analyst
4. Change management analyst
5. Project manager
67
Summary -2-
• The Systems Development Lifecycle consists o
f four stages: Planning, Analysis, Design, and I
mplementation
• The major development methodologies:
1. Structured design
• Waterfall method
• Parallel development
2. RAD development
• Phased Development
• Prototyping
• Throw-away Prototyping
3. Agile development
• Extreme Programming
• Scrum

68
Referensi
1. Alan Dennis et al, Systems Analysis and Design with UML
4th Edition, John Wiley and Sons, 2013
2. Kenneth E. Kendall and Julie E Kendall, Systems Analysis a
nd Design 8th Edition, Prentice Hall, 2010
3. Hassan Gomaa, Software Modeling and Design: UML, Use
Cases, Patterns, and Software Architectures, Cambridge U
niversity Press, 2011
4. Gary B. Shelly and Harry J. Rosenblatt, Systems Analysis an
d Design 9th Edition, Course Technology, 2011
5. Howard Podeswa, UML for the IT Business Analyst 2nd Edi
tion, Thomson Course Technology, 2009
6. Jeffrey A. Hoffer et al, Modern Systems Analysis and Desig
n 6th Edition, Prentice Hall, 2012
69