Entity Relationship Diagram

Tujuan Pembuatan Model :

Untuk
mempermudah
penggambaran
masalah-masalah yang tidak terstruktur,
sehingga pembuatan model adalah jalan
bagi para system analyst untuk membuat
permasalahan tersebut menjadi dalam
sebuah logika struktur yang tepat.

Dua tipe model dalam pengembangan sistem :

1. Model Esensi (Essential Model), menjelaskan
apa (what) yang mewakili permasalahan dalam
sistem. Sistem esensi disebut juga sistem logik
(logical system).
2.
Model
Implementasi
(Implementation
Models), menjelaskan apa (what), serta
bagaimana (how), permasalahan dalam sistem.
Sistem implementasi disebut juga sistem fisik
(physical system).

Teknik Data Modeling :

Merupakan salah satu teknik yang digunakan
dalam pengembangan sistem. Salah satu tools
dalam data modeling adalah dengan membuat
diagram hubungan entitas (Entity Relationship
Diagram, biasa disebut dengan ERD).
ERD adalah alat permodelan data yang
menjelaskan
keterlibatan
atas
kategorikategori yang terdapat dalam sistem dan usaha.
ERD tidak menjelaskan bagaimana data
tersebut diimplementasikan, dibuat, dirubah,
digunakan ataupun dihapus.

Komponen - Komponen ERD

Cardinality
Ordinality

ORDER

0:M

CONTAINS

Relasi Data
Entitas Data

1:M

PRODUCT

Komponen- komponen ERD :

Dalam ERD hanya dikenal dua komponen, yaitu :
1. Entitas Data (Data Entity), adalah apapun
baik yang abstrak maupun nyata, dimana kita
ingin memasukkan data. Selanjutnya akan
disebut dengan kata entitas.
2. Relasi Data (Data Relationship), adalah
keterlibatan wajar yang secara eksis berada
pada satu atau lebih entitas. Selanjutnya akan
disebut dengan kata relasi.

Sub komponen ERD :

a. Sub komponen entitas:

1. Data Attributes (Atribut Data), adalah
karakteristik
yang
dapat
dipergunakan
mempresentasikan semua atau hampir semua
dari entitas bersangkutan.
2. Identifier, adalah sebuah atribut atau
kombinasi atribut unik (unique) yang dapat
menggambarkan satu (dan hanya satu) entitas.

b. Sub komponen relasi data :

1. Ordinality (ordinalitas), menjelaskan apakah
hubungan antara entitas tersebut sebuah
keharusan (mandatory) atau hanya pilihan
(optional), yang bisa juga dianggap sebagai
jumlah minimum.
2. Cardinality (kardinalitas), menjelaskan
jumlah maksimum dari keberadaan sebuah
entitas terhadap keberadaan tunggal lain pada
entitas yang berhubungan.

Langkah-langkah dalam pembuatan ERD

1. Buat daftar fungsi sementara (seperti
proses dan transaksi) yang harus didukung
oleh model data.
2. Buat daftar atribut sementara.
3. Tentukan entitas dan berikan kunci.
4. Gambarkan model umum dari ERD, beri nama
relasi data dan tentukan cardinality.
5. Periksa apakah semua fungsi yang ditentukan
pada langkah 1 telah tercakup pada ERD.

6. Tentukan tabel yang sesuai dengan ERD dan

hapus semua kunci dari daftar atribut.
7. Tempatkan atribut-atribut dari daftar
atribut ke dalam tabel
yang telah
disesuaikan dan hapus atribut
tersebut dari daftar atribut.
8. Buat entitas baru dan hubungan, apabila
terdapat atribut-atribut yang belum
tercakup pada tabel sebelumnya. Apabila
terdapat entitas baru, ulangi langkah 3.
9. Periksa apakah model tersebut telah
mencukupi untuk pengembangan model untuk
kebutuhan akan fungsi baru.

10. Periksa apakah model yang dibuat sudah

benar-benar wajar dan apakah kesemuanya
telah mendukung fungsi sampai tingkatan
atribut. Apabila terdapat
kesalahan
lakukan pengulangan dari langkah 1.
11. Hapus semua relasi data dan entitas data
yang tidak dibutuhkan. Semua definisi dari
model yang dikembangkan harus tercakup
pada database dan semua cardinality harus
diperiksa.
Aturan dalam definisi ERD harus dipenuhi !

Disampaikan Oleh
PROF . DR. SRI MULYANI NS,
SE, MS, AK
ADHI ALFIAN, SE.

Job Description for a System

Analyst
System
development
team manager

System Analyst
(Multiple Job
levels)

A Systems analyst shall be responsible for

studying the problems and needs set forth
by this organizations to determine how
computer hardware, applications software,
files and databases, networks, people, and
procedures can best solve these problems
and improve business and information
systems.

RESPONSIBILITIES
EVALUATE PROJECTS FOR FEASIBILITY
ESTIMATES PERSONEL REQUIREMENTS,
BUDGETS, AND SCHEDULES FOR SYSTEM
DEVELOPMENT AND MAINTENANCE
PROJECTS.
PERFORM INTERVIEWS AND OTHER FACT
GATHERING.
DOCUMENT AND ANALYZES CURRENT
SYSTEM OPERATIONS.
5

DEFINES USER REQUIREMENTS FOR IMPROVING

OR REPLACING SYSTEMS.
IDENTIFIES POTENTIAL APPLICATIONS OF
COMPUTER TECHNOLOGY THAT MAY FULFILL
REQUIREMENTS.
EVALUATES APPLICATIONS OF COMPUTER
TECHNOLOGY FOR FEASIBILITY.
RECOMMENDS NEW SYSTEMS AND TECHNICAL
SOLUTIONS TO END USER AND MANAGEMENT.
IDENTIFIES POTENTIAL HARDWARE AND
SOFTWARE VENDORS, WHEN APPROPRIATE.
RECOMMENDS AND SELECT HARDWARE AND
SOFTWARE PURCHASE.
6

EXTERNAL CONTACTS
ASSIGNED END USERS OF MAINFRAME COMPUTER AND
APPLICATIONS.
ASSIGNED OWNERS MAINFRAME COMPUTER AND
APPLICATIONS.
DATA ADMINISTRATION CENTRE PERSONNEL.
NETWORK ADMINISTRATION CENTER PERSONNEL.
INFORMATION CENTER PERSONNELS.
OPERATIONS CENTER PERSONNELS.
8

METHODOLOGY/CASE EXPERT AND STAFF.

COMPUTER HARDWARE AND SOFTWARE VENDORS.
OTHER SYSTEM ANALYSIS AND DEVELOPMENT
MANAGERS.

MINIMUM QUALIFICATIONS
BACHELOR OR MASTER DEGREE
IN COMPUTER INFORMATION
SYSTEMS OR RELATED FIELD.
PROGRAMMING EXPERINCE
PREFERRED.
PRIOR EXPERIENCE WITH
BUSINESS APPLICATIONS
CONSIDERED HELPFUL.
PRIOR TRAINING OR
EXPERIENCING IN SYSTEM
ANALYSIS AND DESIGN,
PREFERABLY STRUCTURED
METHODS, PREFERRED.
GOOD COMMUNICATIONS
SKILLS - ORAL AND WRITEN ARE
MANDATORY.
10

TRAINING REQUIREMENTS
ANALYST MUST COMPLETE OR DEMONSTRATE
EQUIVALENT BACKGROUNDS IN THE FOLLOWING HOURS COURSES ; STRADIS METHODOLOGY AND
STANDARDS, JOINT APPLICATION DESIGN (JAD)
TECHNIQUES, SYSTEM APPLICATION
ARCHITECTURE (SAA) STANDARDS,
FUNDAMENTALS, DDB DATABASE DESIGN
TECHNIQUES, CSP PROTOTYPING TECHNIQUES,
EXCELERATOR/IS CAD TECHNIQUES, PROJECT
MANAGEMENT TECHNIQUES, MICROCOMPUTER
SOFTWARE TOOLS, AND INTERPERSONAL
COMMUNICATIONS SKILLS FOR SYSTEMS
ANALYSIS.
11

JOB LEVEL
INITIAL ASSIGMENTS ARE BASED ON PROGRAMMING
EXPERIENCING AND TRAINING RESULTS. THE FOLLOWING
JOB LEVELS ARE DEFINED;
PROGRAMMER/ANALYST ; 30% ANALYSIS 70%PROGRAMMING.
ANALYST/PROGRAMMER; 50% ANALYSIS 50%PROGRAMMING.
ANALYST; 70% ANALYSIS 30% PROGRAMMING.
SENIOR ANALYS/DESIGN; 30% MANAGEMENT
60%ANALYSIS/DESIGN & 10% PROGRAMMING.
LEAD ANALYST ; 100% ANALYSIS/DESIGN OR
CONSULTING.
12

Computer
Programming
Experince and
Expertise

Working Knowledge of
Information Systems and
Technology

General
Business
Knowledge

Problem- Solving
Skills

Interpersonal
Communications
Skills
Flexibiliy
and
Adaptabil
ity

Interpersonal
Relations Skills

Character
and Ethics

Preparing for a career as

a SystemAnalyst
13

System Analyst and

Design Skills

System Owner
Owner interested
in the things that
data describes.
The things are
business
resources, such as;
Tangible things
(such as materials,
supplies,
machines) Roles
(such as
costumers,supplies
,empoyees) Events
(Such as
Order,requisitions,
contract)Places
(Such as
sales&offices)

DATA

System User

Entities are
forms, files,
records.
Knowledgeable
about data
attributes.
Knowledgeable
about the rules
(relationship)that
govern data and
entities.

System
Designer

Translate data
requirements into
computer files &
databases. View
of data consists of
record layouts,
data
structures,databa
se schemas,file
organizations,
fields,indexes,
and other
technical items.

15

System Builder
Write data program
to implement the
computer files and
database.

ACTIVITIES
System Owner
System owner are
usually interested
in the big picture
groups of activities
called functions
that consist of
Business, system
functions(eg.
Sales,service,man
ufacturing) and
information system
function(eg. Data
processing,officea
utomation,etc).

System User

System Designer

Users see
activities in terms
of distinct
business process,
Business process
are distinct
activities that have
inputs and
outputs(process
models, for short),
Specify methods
and step-by-step
procedurs often
underlie these
process.

16

System designers
view activities are
constrained by the
limitations of
specific
technology. In
other word, the
designers view of
activities is more
technical

System
Builder
System builder
represent
activities using
precise
computer
programming
language that
describe inputs,
outputs, and
logic. These
languages are
used to write
applications
programs.

NETWORK
System Owner

System User

System Designer System Builder

System owner
view networks
geographical.The
geography of a
system is those
geographic
locations in which
the business
choose or needs to
operate.

System users think in

terms of business
networks. A business
network defines
detailed working
locations, specifis
resources available at
each locations & the
business
communications
requirements between
those locations. A
business network
doesnt necessarily
require computer
network. A business
network is sometimes
called a logistic
network.
17

Systems designers
view network in
term of computer
network. Computer
network is
technical
arrangement that
interconnects
computers and
peripherals such
that they can
change data &
share technical
resources. It is
sometimes called a
distributed system
architecture.

System builder use

telecommunications
languages &
standards to write
network programs.
Network programs
are machinereadable
specifications of
computer
communications
parameters such as
node addreses,
protocols, line
speeds,flow
controls,and other
complex technical
parameters.

Technologies
Data
Processing Communications Technical
Technology Technology Technology
Specialist.
Includes all
hardware and
software
required to
capture,store
and manage
the data
resources.

Includes all
hardware and
software
required to
support
business and
information
system
activiies. It
also inlude
applications
programs.

Also called
networking or
telecommunications
technology includes
hardware &
software used to
interconnect data
and process
technology at
different locations.

18

Technical
specialist sell,
configure,repa
ir,and
maintain
information
technology for
systems
owners and
users.

System Development Life Cycle (SDLC), Joint Application

Development Technique, The Prototyping and Rapid
Application Development Technique

A system Development Life Cycle (SDLC) is a

process by which systems analysts, software
engineers, programmers, and end-user build
information systems and computer applications.
Prototyping is a popular engineering
technique used to develop a small scale working
(or simulated) model of product or its
component.
19

Joint Application Development (JAD) is

a highly structured workshop that brings
together users, managers, and
information systems specialists to jointly
define and specify user requirements,
technical options, and external design
(inputs, outputs, and screen).
Rapid Application Development (RAD)
is the merger of various structured
techniques (especially the data-driven
information engineering) with
prototyping techniques and joint
application development techniques to
20
accelerate systems development.

Keuntungan
S DL C

RA D

Merupakan
metoda yang paling
awal

Help The analysts

and users to verify
the requirements,
and to formally
refine the data and
process models.
Combined
business
requirements and
technical design
statement.
21

Kelemahan
End-User tidak terlibat terlalu aktif
dalam penyusunan system.
Pada saat implementasi sistim
kemungkinan akan banyak modifikasi
sistem.

Prototy
ping

K ekuatan

K elemahan

End-User become
more active
participants in
systems
development.
They tend to be
more excited by
working protypes
than paper design
specification.
Requirements
definition is
simplified through
realization that
many end-user
will not
understand or be
able to state their
detailed
requirements until
they see a
prototypes.

..tend to skip through analysis and design

phases too quickly. This encourage the
analysis to jump too quickly into code
without understanding problems and
requirements.
..can discourage the consideration of
alternate technical solutions. They analyst
tend to go with the first prototype
alternative that receives a reasonably a
favorable reaction from users.
Systems implemented from prototypes
fequently suffer from lack of flexibility to
adapt to changing requirements-they were
developed quick and dirty
Prototyprs are not always easy to change.
Several expert have noted the growing
libraries of poory designed, unstructured,
and inaduquately documented 4 GL code.
Prototypes are rarely polished. The
technology used can actually inhibit user
comprehension and, subsequently,
22discourage participation.

Kekuatan
J AD

..tends to improve the relationship between users,

management and information systems professionals.
..tends to improve the computer literacy of users and
management as well as the business and application
literacy of information systems specialists.
..places the responsibility of conflict resolution where it
belongs-on-the shoulders of both business users and
management.
..usually decreases elapsed systems development time
by consolidating multiple interviews into the structured
workshop.
..usually lowers the cost of systems development by
getting the requirements correctly defined and prioritized
the first time.
..ususally results in greater systems value and
user/management satisfaction. It increases user and
management confidence and support of the project.
..usually results in systems that cost less to maintain
because the first version already fulfill requirements.

23

RAD

Keuntungan

Kelemahan

Help the analyst

and users to verify
the
requirements,
and
to
formally
refine the data and
process models
Combined
business
requirements
and
technical
design
statement
24

The systems Planning function of the life

cycle seeks to identify and prioritize
those technologies and application that
will return the most value to business.
Synonims include strategic systems
planning, information strategic planning,
and information resource management.
25

Phase of Systems Planning

Study the Business
Mission.
Define an Information
Architecture.
Analyze Business Area.

26

Roles

Techniques

Input

Output

Establish The Planning Team

g

Top
Management

There are no
special techniques
or skilled required
to complete this
activity

Role
definition

assignment

Define Planning Scope and Expectation

Consultant
Planning
analyst
CIO

Fact finding
Based on
Organization

JAD
interviews
charts.
Context or Scope
and facilitated
Context
modelimg
group
models
discussion
(scopewithin the
oriented
planning
pictures)
team, the
Scope

scope of the
description.
project
27
defined

Roles
Technique
Input
Output
Identify Busimess Performance Measures

Planning
Team

Executive
Manager

Fact finding
JAD

The scope
as defined
in the
previous
activity

Business
performance
measures

Develop a profrect Plan

Planning
Team

Project
Management

The scope
as defined in
the previous
activity

Project plan
Budget

Review Findings and Communicate Planning Vision

Planning
Team
Executive

manager

Feasibility
Appropriate
Planning

Assesment
documentation
Project charter
Report
writing
Verbal

Presentation28

Roles

Techniques

Input

Output

Model the Enterprise

Planning
team with
help from
appropriate
executive
managers

Fact finding
Joint
application
development
Data

modeling
Process

modeling
Network

modeling

Scope (from
Enterprise

the study phase)

models.
Any existing

models.

Asset Current Business Strategies

Planning
team &
appropriate
executive
managers

Interviewing
Performance
Sampling
measures
Studying
The enterprise

Joint
models
application
Design
29

Roles

Technique

Input

Output

Asset Current Information Service and Strategies

Planning
team
and
apropriate
executive
managers

Interviewing
Sampling
Studying
Joint
application
design

Business
performance
measures

and
Technology
application assesments in
various formats such as
questionnaire
response
summaries,
association
matrixces, and narrative
analyses.

Identify and Prioritize Business Area

Planning
Team

Affinity
analysis
Clustering

Enterprise
Proposed business area
models
(specifically,da
ta
subjects,
business
process
&
organization
units)
Business
performance
measures
Association
matrices
30

Roles

Technique

Input

Output

Complete The New Information Architecture

Planning
There are
Proposed
Proposed

team
and
no
special
business
information
optionally
techniques or
area
and
architecture
unbiased
skilled require
enterprise
experts
or
to complete
models
consultants
this activity
Technology

and
information
service
assessments
Technology

trends
and
insights

Identify and Plan Subsequent Projects

Planning
Team

Project
Business

Planning
area Models
Schedulling
Proposed

Information
31
architecture

Projects
Plans

Rol es

Techniques

Input

Output

Review Findings and Approve The Plan

Planning
Team
Top
Executive

Feasibility
Appropria Approved
assesment
te
information
Report writing
documentati architecture
Walkthroughs
ons
and plan
Verbal
presentations

32

Roles

Techniques
Input
Establish the Analysis Team

Executive There are no

sponsor
special
CIO
techniques

Business
area details

Output
Roles

Identify Business Area Performance Measures

Analysis Fact finding
team with Joint
help from
application
business
development
managers
(JAD)
and
appropriate
business
experts
33

Overall
Business
business
area
performance
performance
measures
measures

Roles

Techniques

Input

Output

Model the Business Area

Analysis
team with
help from
business
managers
and
appropriate
business
experts

Fact finding
JAD
Data modeling
Process
Modeling
Network
Modeling

Analysis
team with
help from
business
managers
and
appropriate
business
experts

Interviewing
Observations
Sampling
Studying
Joint
Application
Design

Business
area subset
of business
models

Expanded and
refined
business area
models

Access Curent Business Area and IS Performance

34

Business
area models
Business
performance
measures

Association
matrices and
interpretations

Roles

Techniques

Input

Output

Identify and prioritize development projects

Analysis
team

There are no
special
techniques

Business
area models
Association

matrices
interpretations

Proposed
development
projects and
technology
architecture

Proposed
development
projects

Plan Application development strategy and projects

Analysis
Team

Project
planning
Schedulling

35

Planned
development
projects

Roles

Techniques

Input

Output

Review Findings and approve the plan

Analysis team
Business
managers
CIO

Planning Team

Feasibility
Appropriate
Planned

assesment
documentation
application
Report writing
development

Walkthroughs
projects

Verbal
Planned

presentations
database and/or
network
development
project(s),
Business area

plan

36

Roles

Technique

Input

Output

Identify Requirements
System
Users
System

owner(s) with
direction by
systems
analyst

System
analyst
System
user
System
Owner(s)
Data
analyst
Network
analyst

Interviewing
New

Group Meetings
System
Discussions
objectives
Surveys
(and
Research
constraints)
Brainwriting
Brainstorming

Business and
user requirements

Model System Requirements

Data
modeling
Process

Modeling
Network

modeling

Business &
user
requirements
Current

system details
(and possibly
programs)
Models from

strategic
planning

37

Proposed
systems models

Roles

Techniques

Input

Output

Build Discovery Prototypes (if necessary)

-

System
Analyst
System

Owners
Systems

users

Business &
Prototypes
User
& Refined
requirements
requirements

Prioritize Business Requirements

System
Owner
System

Users

There are
no tangible
skills required
except for
experience

38

Proposed

systems
requirements
Models and

prototypes

Priorities

Roles
System
Analyst
System

owners

Techniques
Input
Output
Modify Project Scope and Plan
Function point
analysis
Project

management

Proposed
system
requirements
Prioritize

system
models
Projects

plan & size

estimates

Modified
project plan
and size
estimates

Review Requirements Specifications

System
Analyst

Feasibility
assessment
Report writing

Walkthroughs

Verbal

presentations

39

Appropriate
Business
supporting
requirements
documentation
statements

System Design
System Design is the
evaluation of alternative
solutions and the specification
of a detailed computer-based
solution. It is also called
physical design.
40

SELECT a DESIGN TARGET

There are two fundamental
objectives in the selection phase
To identify and research alternative manual and
computer-based solutions to support our target
information system.
To evaluate the feasibility of alternative solutions
and recommend the best overall alternative
solution.
41

Roles

Techniques
Input
Specify Alternative Solutions
-

Analyst

Business
Requirements
Approved
technology
architecture
Ideas

Output

Candidate
solutions

Analyze Feasibility of Alternative Solutions

Analyst,
owners
and users

Feasibility Candidate
assessment
solutions
Technical
opinions
Attitude
opinions
Cost and
42 benefits

Feasibility
analysis

Roles

Techniques

Input

Output

Recommend a System Solutions

Analyst Feasibility
Project
Changes
and
assessment
plan
to
owners
proposed
Report
Sizes
writing
estimates
design
Verbal
Candidate System
presentations
solutions
proposal
Feasibility
analysis

43

Roles

Techniques

Input

Output

Recommend a System Solutions

Analyst Feasibility
Project
Changes
and
assessment
plan
to
owners
proposed
Report
Sizes
writing
estimates
design
Verbal
Candidate System
presentations
solutions
proposal
Feasibility
analysis

43

Acquire Necessary Hardware

and Software
There are four fundamental objectives of the
acquisition phase
To identify and research specific products that
could support our recommended solution for the
target information system.
To solicit, evaluate, and rank vendor proposal
To establish requirements for integrating the
awarded vendors products.
44

Roles

Techniques
Input
Output
Research Technical Criteria and Options
_

Analyst

Hardware
Potential
and Software
vendors
requirements Options
Product and Technical
vendor facts
criteria

Solicit Proposals (or quotes) from vendors.

Analyst

Report writing Potential

Developing
vendors
questionnaires Options
Technical
criteria

45

RFP or
RFQ and
selection
criteria

Roles

Techniques

Input

Output

Validate Vendor Claims and Performances

Analyst

Demonstration

Validation
Criteria
Test
Results
Findings
Proposal
and
quotation

Validated
proposal

Evaluate and Rank Vendor Proposals

Analyst

Feasibility
assessment

Evaluation Hardware
criteria
and
Software
Validated
Proposals
recommen
dation

46

Roles

Techniques Input

Output

Award Contract and Debrief Losing Vendors

Analyst

Hardware and
software
recommendation
Not validated
proposals
Hardware and
software
approval

Hardware and
software aspecs
Debrief of
proposal
Contract and
order
Hardware and
software
recommendation

Establish Integration Requirements

Analyst

Hardware
and Software
spec
47

Integration
requirement

Design Integrated New System

Roles

Techniques
Input
Output
Analyze and Distributed Data

Analyst
with users

Data analysis
Normalization
Event
analysis

Normalized
distributed
data models
and revised
process
models

Analyzed and Distributed Process

Analysts,
designers
and users

Data
model
diagram
Target
solution

48

Distributed
process
models