Silahkan yang ingin menjadi seorang analyst system dibaca slidenya !

1. CChhaapptteerr 11
1

2. Key Ideas
Many failed systems were abandoned because
analysts tried to build wonderful systems without
understanding the organization.
The primarily goal is to create value for the
organization.
2

3. Key Ideas
The systems analyst is a key person analyzing the
business, identifying opportunities for
improvement, and designing information systems
to implement these ideas.
It is important to understand and develop
through practice the skills needed to successfully
design and implement new information systems.
3

4. 4

5. Project Phases
Planning (Why build the system? How should the
team go about building it?)
Analysis (Who uses system, what will it do, where
and when will the system be used?)
Design (How will the system work?)
Implementation (System delivery)
5

6. Planning
Identifying business value
Analyze feasibility
Develop work plan
Staff the project
Control and direct project
6

7. Analysis
Analysis strategy
Gathering business requirements
Requirements definition use cases
Process modeling
Data modeling
7

8. Design
Design selection
Architecture design
Interface design
Data storage design
Program design
8

9. Implementation
Construction
Program building
Program and system testing
Installation
Conversion strategy
Training plan
Support plan
9

10. Processes and Deliverables
10
Process Product
Planning
Analysis
Design
Implementation
System Request
Feasibility Analysis
Workplan
System Proposal
System
Specification
New System and
Maintenance Plan

11. 11

12. 12

13. 13
Pros Cons
Identifies systems
requirements long
before programming
begins
Minimizes changes to
requirements as
project progresses
Design must be
specified on paper
before programming
begins
Long time between
system proposal and
delivery of new
system

14. 14

15. 15
Pros Cons
Reduces Schedule
Time
Less Chance of
Rework
Still Uses Paper
Documents
Sub-projects May Be
Difficult to Integrate

16. 16
Incorporate special techniques and tools:
CASE tools
JAD sessions
Fourth generation/visualization programming
languages
Code generators

17. 17
Phased development
A series of versions developed sequentially
Prototyping
System prototyping
Throw-away prototyping
Design prototyping

18. 18
Insert Figure 1-4 here

19. 19
Pros Cons
Users Get a System
To Use Quickly
Users Can Identify
Additional Needs
For Later Versions
Users Work with a
System that is
Intentionally
Incomplete

20. 20

21. 21
Pros Cons
Users Interact with
Prototype Very Quickly
Users Can Identify
Needed Changes
And Refine Real
Requirements
Tendency to do
Superficial Analysis
Initial Design
Decisions May
Be Poor

22. 22

23. 23
Pros Cons
Risks are Minimized
Important Issues are
Understood Before the
Real System is Built
May Take Longer
Than Prototyping

24. 24

25. 25
Pros Cons
Fast Delivery of Results
Works Well in Projects
With Undefined or
Changing Requirements
Requires Discipline
Works Best in
Small Projects
Requires Much
User Input

26. Object-Oriented Approach
26

27. Criteria for Selecting the Appropriate Methodology
Clear user requirements
Familiarity with technology
Complexity of system
Reliability of system
Time schedule
Schedule visibility
27

28. Basic Step to develop an Object Oriented Systems
Identifying business value
Analyze feasibility
Develop workplan
Staff the project
Control and direct project
Requirements determination
Functional modeling
Structural modeling
Behavioral modeling
Moving on to design
28

29. Chapter 2
29

30. Key Ideas
An opportunity to create business value from using
information technology initiates a project.
Feasibility analysis helps determine whether or not to
proceed with the IS project.
Projects are selected based on business needs and
project risks.
30

31. Key Ideas
The project sponsor is a key person who identifies
business value to be gained from using
information technology.
The approval committee reviews system requests
from groups throughout the organization and
selects projects for the benefit of the business.
31

32. 32
IIDDEENNTTIIFFYYIINNGG PPRROOJJEECCTTSS
WWIITTHH BBUUSSIINNEESSSS VVAALLUUEE

33. How Do Projects Begin?
Business needs should drive projects.
Project sponsor recognizes business need for new
system and desires to see it implemented.
Business needs determine the system’s functionality
(what it will do).
The project’s business value should be clear.

34. System Request
A document describing business reasons for project
and system’s expected value.
Lists project’s key elements
Project sponsor
Business need
Business requirements
Business value
Special issues or constraints

35. System Request Examples
Project sponsor – VP of Marketing
Business need – Reach new customers and
improve service to existing customers
Business requirements – Provide web-based
shopping capability
Business value - $750,000 in new customer sales;
$1.8M in existing customer sales
Special issues or constraints – System must be
operational by holiday shopping season

36. Preliminary Project
Acceptance
System request is reviewed by approval committee
Based on information provided, project merits are
assessed.
Worthy projects are accepted and undergo additional
investigation – the feasibility analysis.

37. Feasibility Analysis
Detailed business case for the project
Technical feasibility
Economic feasibility
Organizational feasibility
Compiled into a feasibility study
Feasibility is reassessed throughout the project
37

38. Technical Feasibility: Can We Build It?
Users’ and analysts’ familiarity with the business
application area
Familiarity with technology
Have we used it before? How new is it?
Project size
Number of people, time, and features
Compatibility with existing systems

39. Economic Feasibility: Should We Build It?
Identify costs and benefits
Assign values to costs and benefits
Determine cash flow
Assess financial viability
Net present value (NPV)
Return on investment (ROI)
Break even point(BEP)

40. 40
Costs Benefits
Tangible
Intangible
***
***
***
***

41. Assign Cost and Benefit Values
Difficult, but essential to estimate
Work with people who are most familiar with the
area to develop estimates
Intangibles should also be quantified
If intangibles cannot be quantified, list and include as
part of supporting material

42. Organizational Feasibility: If we build it, will they come?
Strategic alignment
How well do the project goals align with business
objectives?
Stakeholder analysis
Project champion(s)
Organizational management
System users

43. Project Selection
Approval committee works from the system request
and the feasibility study
Project portfolio – how does the project fit within the
entire portfolio of projects?
Trade-offs must be made to select projects that will
form a balanced project portfolio
Viable projects may be rejected or deferred because of
project portfolio issues.

44. Chapter 3
44

45. Key Definitions
Project management is the process of planning
and controlling the development of a system
within a specified timeframe at a minimum cost
with the right functionality.
A project manager has the primary responsibility
for managing the hundreds of tasks and roles that
need to be carefully coordinated.
45

46. Four Key Steps in Managing Projects
Identifying project size
Creating and managing the workplan
Staffing the project
Coordinating and controlling project activities
46

47. 47

48. 48
Project Management involves
making trade-offs… Project Size
Project Cost
Project Time
Modifying one element
requires adjusting the others

49. Project Estimation
The process of assigning projected values for time
and effort
Sources of estimates
Methodology in use
Actual previous projects
Experienced developers
Estimates begin as a range and become more specific
as the project progresses
49

50. 50
Planning Analysis Design Implementation
Industry
Standard
For Web 15% 20% 35% 30%
Applications
Time
Required 4 5.33 9.33 8
in Person
Months

51. Converting Function Points to Lines of Code
51
Language LOC ratio
CC
OBOL
JAVA
C++
Turbo Pascal
Visual Basic
PowerBuilder
HTML
Packages
(e.g., Access, Excel)
130
110
55
50
50
30
15
15
10-40
Source: Capers Jones, Software Productivity Research

52. 52

53. 53
Work Plan Information Example
Name of task Perform economic feasibility
Start date ` Jan 05, 2003
Completion date Jan 19, 2003
Person assigned Mary Smith, sponsor
Deliverable(s) Cost-benefit analysis
Completion status Open
Priority High
Resources needed Spreadsheet
Estimated time 16 hours
Actual time 14.5 hours

54. Identifying Tasks
Methodology
Using standard list of tasks
Top-down approach
Identify highest level tasks
Break them into increasingly smaller units
Organize into work breakdown structure
54

55. Project Workplan
List of all tasks in the work breakdown structure, plus
Duration of task
Current task status
Task dependencies
Key milestone dates
55

56. Tracking Project Tasks
Gantt Chart
Bar chart format
Useful to monitor project status at any point in time
PERT Chart
Flowchart format
Illustrate task dependencies and critical path
56

57. 57
Task Week
Go to Library
Go to Bookstore
Select and Purchase Book
Skim Book
Write Phase One
Read Book Carefully
Write Phase Two
2 3 4 5 6 7 8 9 10 11 12 13

58. 58
Go to Library
4 weeks
Select and
purchase book
Go to Bookstore 1 week
4 weeks
Skim book
3 weeks
Write Phase One
2 weeks
Read book carefully
3 weeks
Write Phase Two
3 weeks

59. 59

60. Staffing Attributes
Staffing levels will change over a project’s lifetime
Adding staff may add more overhead than additional
labor
Using teams of 8-10 reporting in a hierarchical
structure can reduce complexity
60

61. 61

62. 62

63. 63
Planning Analysis Design Implementation
Upper CASE Lower CASE
Integrated CASE (I-CASE)

64. Diagrams Screen
Procedural Metadata
64
Logic
Designs
CASE Repository

65. Standards
Examples
Formal rules for naming files
Forms indicating goals reached
Programming guidelines
65

66. Documentation
Project binder
Table of contents
Continual updating
66

67. Managing Risk
Risk assessment
Actions to reduce risk
Revised assessment
67

68. Classic Mistakes
Overly optimistic schedule
Failing to monitor schedule
Failing to update schedule
Adding people to a late project
68

69. Chapter 4
69

70. Key Definitions
The As-Is system is the current system and may or
may not be computerized
The To-Be system is the new system that is based on
updated requirements
The System Proposal is the key deliverable from the
Analysis Phase
70

71. Key Ideas
The goal of the analysis phase is to truly understand the
requirements of the new system and develop a system that
addresses them -- or decide a new system isn’t needed.
The System Proposal is presented to the approval
committee via a system walk-through.
Systems analysis incorporates initial systems design.
Requirements determination is the single most critical
step of the entire SDLC.
71

72. What is a Requirement?
A statement of what the system must do
A statement of characteristics the system must have
Focus is on business user needs during analysis phase
Requirements will change over time as project moves
from analysis to design to implementation
72

73. Requirement Types
Functional Requirements
A process the system hast to perform
Information the system must contain
Nonfunctional Requirements
Behavioral properties the system must have
Operational
 Performance
 Security
 Cultural and political
73

74. Documenting Requirements
Requirements definition report
Text document listing requirements in outline form
Priorities may be included
Key purpose is to define the project scope: what is
and is not to be included.
74

75. Basic Steps of Determining Requirements
Understand the “As-Is” system
Identify improvement opportunities
Develop the “To-Be” system concept
Techniques vary in amount of change
Business Process Automation (BPA) – small change
Business Process Improvement (BPI) - moderate change
Business Process Reengineering (BPR) – significant change
Additional information gathering techniques are needed
as well
75

76. Chapter 5
76

77. Key Ideas
Functional models describe business processes
and the interaction of an information system with
its environment.
Two types of models are used to describe
functional models: Activity Diagrams and Usecase
Diagrams
Activity diagrams support the logical modeling of
business processes and workflows.
Usecase Diagrams are used to describe the basic
functions of the information system.
77

78. Elements of an Activity Diagram
Actions/Activities
Object Nodes
Object Flows
Control Nodes
Control Flows
Swimlanes
78

79. Activity Diagram
79

80. What are Use-Case Descriptions?
Describe basic functions of the system
What the user can do
How the system responds
Use cases are building blocks for continued design
activities.
80

81. How Are Use-Cases Created?
Two steps:
Write text-based case descriptions
Translate descriptions into diagrams
Describes one and only one function, but may
have multiple paths.
Developed working with users for content.
81

82. Types of Use-Cases
Overview versus detail
Essential versus real
82

83. 83
Use Case Name: ID: Importance Level:
Primary Actor: Use Case Type:
Stakeholders and Interests:
Brief Description:
Trigger:
Relationships: (Association, Include, Extend, Generalization)
Normal Flow of Events:
Subflows:
Alternate/Exceptional Flows:

84. 84

85. 85

86. Chapter 6
86

87. Key Definitions
Data model
A formal way of representing the data that are used and
created by a business system
Shows the people, places and things about which data
is captured and the relationships among them.
Logical data model
shows the organization of data without indicating how
it is stored, created, or manipulated.
87

88. Key Definitions
Physical data model
shows how the data will actually be stored in databases
or files.
Normalization is the process analysts use to validate
data models.
Data models should balance with process models
88

89. 89

90. What Is an ERD?
A picture showing the information created, stored,
and used by a business system.
Entities generally represent similar kinds of
information
Lines drawn between entities show relationships
among the data
High level business rules are also shown
90

91. Using the ERD to Show Business Rules
Business rules are constraints that are followed when
the system is in operation.
ERD symbols can show when one instance of an
entity must exist for an instance of another to exist
A doctor must exist before appointments the doctor
can be made
91

92. ERD symbols can show when one instance of an
entity can be related to only one or many
instances of another entity
One doctor can have many patients; each patient may
have only one primary doctor
ERD symbols show when the existence of an
entity instance is optional for a related entity
instance
A patient may or may not have insurance coverage
92

93. 93

94. Entity
A person, place, event, or thing about which data
is collected
Must be multiple occurrences to be an entity
Example: If a firm has only one warehouse, the
warehouse is not an entity. However, if the firm has
several warehouses, the warehouse could be an entity if
the firm wants to store data about each warehouse
instance.
94

95. 95

96. Attributes
Information captured about an entity
Only those used by the organization should be
included in the model
Attribute names are nouns
Sometimes entity name is added at the beginning of
the attribute name for clarity
96

97. Identifiers
One or more attributes can serve as the entity
identifier, uniquely identifying each entity
instance
Concatenated identifier consists of several
attributes
An identifier may be ‘artificial,’ such as creating
an ID number
Identifiers may not be developed until the Design
Phase
97

98. 98

99. Relationships
Associations between entities
The first entity in the relationship is the parent entity;
the second entity in the relationship is the child entity
Relationships should have active verb names
Relationships go in both directions
99

100. 100
Cardinality
refers to the number of times instances in one entity
can be related to instances in another entity
One instance in an entity refers to one and only one
instance in the related entity (1:1)
One instance in an entity refers to one or more instances
in the related entity (1:N)
One or more instances in an entity refer to one or more
instances in the related entity (M:N)

101. 101
Modality
Refers to whether or not an instance of a child entity
can exist without a related instance in the parent entity
Not Null means that an instance in the related entity must
exist for an instance in another entity to be valid
Null means that no instance in the related entity is
necessary for an instance in another entity to be valid

102. 102

103. ERD Basics
Drawing the ERD is an iterative process of trial and
revision
ERDs can become quite complex
103

104. Steps in Building ERDs
Identify the entities
Add appropriate attributes for each entity
Draw the relationships that connect associated
entities
104

105. Identify the Entities
Identify major categories of information
If available, check the process models for data stores,
external entities, and data flows
Check the major inputs and outputs from the use cases
Verify that there is more than one instance of the
entity that occurs in the system
105

106. Add Appropriate Attributes
Identify attributes of the entity that are relevant to the
system under development
Check the process model repository entries for details on
data flows and data stores
Check the data requirements of the requirements definition
Interview knowledgeable users
Perform document analysis on existing forms and reports
Select the entity’s identifier
106

107. Draw the Relationships
Start with an entity and identify all entities with
which it shares relationships
Describe the relationship with the appropriate
verb phrase
Determine the cardinality and modality by
discussing the business rules with knowledgeable
users
107

108. ERD Building Tips
Only include entities with more than one instance
of information
Don’t include entities associated with
implementation of the system (they will be added
later)
108

109. 109

110. 110
Best practices rather than rules
Entities should have many occurrences
Avoid unnecessary attributes
Clearly label all components
Apply correct cardinality and modality
Break attributes into lowest level needed
Labels should reflect common business terms
Assumptions should be clearly stated

111. 111
Technique used to validate data
models
Series of rules applied to logical data
model to improve its organization
Three normalization rules are
common

112. 112

113. Chapter 7
113

114. Key Ideas
A structural or conceptual model describes the
structure of the data that supports the business
processes in an organization..
The structure of data used in the system is
represented through class diagrams, and object
diagrams.
114

115. Purpose of Structural Models
Reduce the “semantic gap” between the real
world and the world of software
Create a vocabulary for analysts and users
Represent things, ideas, and concepts of
importance in the application domain
115

116. Classes
Templates for creating instances or objects
Concrete
Abstract
Typical examples:
Application domain, user interface, data
structure, file structure, operating
environment, document, and multimedia
classes
116

117. Attributes
Units of information relevant to the description of the
class
Only attributes important to the task should be
included
117

118. Operations
Action that instances/objects can take
Focus on relevant problem-specific operations (at this
point)
118

119. Relationships
Generalization
Enables inheritance of attributes and operations
Aggregation
Relates parts to wholes
Association
Miscellaneous relationships between classes
119

120. 120

121. 121

122. Class Diagram Syntax
122
A CLASS
AN ATTRIBUTE
AN OPERATION
AN ASSOCIATION
Class 1
-attribute
+operation ()
Attribute name/
derived attribute name
operation name ()
1..* 0..1
______verb phrase____

123. More on Attributes
Derived attributes
/age, for example can be calculated from birth date and
current date
Visibility
Public
Protected
Private
123

124. More on Operations
Constructor
Creates object
Query
Makes information about state available
Update
Changes values of some or all attributes
124

125. More on Relationships
Class can be related to itself (role)
Multiplicity
Exactly one, zero or more, one or more, zero or one,
specified range, multiple disjoint ranges
Association class
125

126. Simplifying Class Diagrams
The view mechanism shows a subset of information
Packages show aggregations of classes (or any
elements in UML)
126

127. 127

128. Object Identification
Textual analysis of use-case information
Nouns suggest classes
Verbs suggest operations
Creates a rough first cut
Common object list
Incidents
Roles
128

129. Patterns
Useful groupings of classes that recur in various
situations
Transactions
Transaction class
Transaction line item class
Item class
Location class
Participant class
129

130. Chapter 8
130

131. Key Ideas
Behavioral models describe the internal dynamic
aspects of an information system that supports
business processes in an organization
Key UML behavioral models are: sequence
diagrams, collaboration diagrams, and statechart
diagrams
131

132. Purpose of Behavioral Models
To depict the internal view of business processes
To show the effects of varied processes on the system
132

133. Interaction Diagram Components
Objects
Operations
Messages
133

134. Sequence Diagrams
Illustrate the objects that participate in a use-case
Show the messages that pass between objects for a
particular use-case
134

135. 135

136. 136
AN ACTOR
AN OBJECT
A LIFELINE
A FOCUS OF CONTROL
A MESSAGE
OBJECT DESTRUCTION
anObject:aClass
aMessage()
x

137. 137
Determine the context of the sequence diagram
Identify the participating objects
Set the lifeline for each object
Add messages
Place the focus of control on each object’s lifeline
Validate the sequence diagram

138. 138
Essentially an object diagram that shows message
passing relationships instead of aggregation or
generalization associations.
Emphasize the flow of messages among objects,
rather than timing and ordering of messages

139. 139

140. Chapter 9
140

141. Key Definitions
The navigation mechanism provides the way for users to
tell the system what to do
The input mechanism defines the way the system captures
information
The output mechanism defines the way the system
provides information to users or other systems
141

142. Key Definitions
The graphical user interface (GUI) is the most
common type of interfaces most students are likely to
use personally and for developing systems.
142

143. 143

144. Basic Principles
Assume users
Have not read the manual
Have not attended training
Do not have external help readily at hand
All controls should be clear and understandable
and placed in an intuitive location on the screen.
144

145. Basic Principles
Prevent mistakes
Limit choices
Never display commands that can’t be used (or “gray
them out”)
Confirm actions that are difficult or impossible to undo
Simplify recover from mistakes
Use consistent grammar order
145

146. Types of Navigation Control
Languages
Command language
Natural language
Menus
Generally aim at broad shallow menu
Consider using “hot keys”
Direct Manipulation
Used with icons to start programs
Used to shape and size objects
May not be intuitive for all commands
146

147. 147

148. 148

149. 149

150. 150
Types of Menus
Menu bar
Drop-down menu
Pop-up menu
Tab menu
Toolbar
Image map
When
Would You
Use Each of
These Menu
Types?

151. Message Tips
Should be clear, concise, and complete
Should be grammatically correct and free of jargon
and abbreviations (unless they are the users)
Avoid negatives and humor
151

152. 152
Types of Messages
Error message
Confirmation message
Acknowledgment message
Delay message
Help message
When
Would You
Use Each of
These
Message
Types?

153. 153

154. 154

155. Basic Principles
The goal is to simply and easily capture accurate
information for the system
Reflect the nature of the inputs
Find ways to simplify their collection
155

156. Online versus Batch Processing
Online processing immediately records the transaction in
the appropriate database
Batch processing collects inputs over time and enters
them into the system at one time in a batch
Batch processing simplifies data communications and
other processes, but means that inventory and other
reports are not accurate in real time
156

157. Capture Data at the Source
Reduces duplicate work
Reduces processing time
Decreases cost
Decreases probability of error
157

158. Source Data Automation
Can be obtained by using the following technologies:
bar code readers
optical character recognition
magnetic stripe readers
smart cards
How can internet be used for source data
automation?
158

159. Minimize Keystrokes
Never ask for information that can be obtained in
another way
List selection is more efficient than entering
information
Use default values where possible
159

160. Types of Inputs
Data items linked to fields
Text
Numbers
Selection boxes
160

161. 161

162. 162
Types of Boxes
Check box
Radio button
On-screen list box
Drop-down list box
Combo box
Slider
When
Would You
Use Each of
These
Box
Types?

163. 163
Types of Validation
Completeness check
Format check
Range check
Check digit check
Consistency check
Database checks
When
Would You
Use Each of
These
Validation
Methods?

164. 164

165. Basic Principles
Understand report usage
Reference or cover-to-cover?
Frequency?
Real-time or batch reports?
Manage information load
All needed information, no more
Minimize bias
165

166. 166
Types of Reports
Detail reports
Summary report
Turnaround document
Graphs
When
Would You
Use Each of
These
Report
Types?

167. 167
Electronic
Versus Paper