apsi - analisa perancangan sistem informasi
DESCRIPTION
Silahkan yang ingin menjadi seorang analyst system dibaca slidenya !TRANSCRIPT
Chapter 1Chapter 1
1
Key IdeasMany 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
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
Project PhasesPlanning (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
PlanningIdentifying business valueAnalyze feasibilityDevelop work planStaff the projectControl and direct project
6
AnalysisAnalysis strategyGathering business requirementsRequirements definition use casesProcess modelingData modeling
7
DesignDesign selectionArchitecture designInterface designData storage designProgram design
8
ImplementationConstruction
Program buildingProgram and system testing
InstallationConversion strategyTraining planSupport plan
9
Processes and Deliverables
10
Process Product
Planning
Analysis
Design
Implementation
System RequestFeasibility Analysis
Workplan
System Proposal
System Specification
New System and Maintenance Plan
11
12
13
Pros Cons
Identifies systems requirements long before programming begins
Minimizes changes to requirements asproject progresses
Design must be specified on paper before programming begins
Long time between system proposal and delivery of new system
14
15
Pros Cons
Reduces Schedule Time
Less Chance ofRework
Still Uses PaperDocuments
Sub-projects May BeDifficult to Integrate
16
Incorporate special techniques and tools:CASE toolsJAD sessionsFourth generation/visualization programming
languagesCode generators
17
Phased developmentA series of versions developed sequentially
PrototypingSystem prototyping
Throw-away prototypingDesign prototyping
18
Insert Figure 1-4 here
19
Pros Cons
Users Get a SystemTo Use Quickly
Users Can IdentifyAdditional NeedsFor Later Versions
Users Work with aSystem that isIntentionally Incomplete
20
21
Pros Cons
Users Interact withPrototype Very Quickly
Users Can IdentifyNeeded ChangesAnd Refine RealRequirements
Tendency to doSuperficial Analysis
Initial Design Decisions May
Be Poor
22
23
Pros Cons
Risks are Minimized
Important Issues areUnderstood Before the
Real System is Built
May Take LongerThan Prototyping
24
25
Pros Cons
Fast Delivery of Results
Works Well in ProjectsWith Undefined or
Changing Requirements
Requires Discipline
Works Best in Small Projects
Requires MuchUser Input
Object-Oriented Approach
26
Criteria for Selecting the Appropriate Methodology
Clear user requirementsFamiliarity with technologyComplexity of systemReliability of systemTime scheduleSchedule visibility
27
Basic Step to develop an Object Oriented Systems
Identifying business valueAnalyze feasibilityDevelop workplanStaff the projectControl and direct projectRequirements determinationFunctional modelingStructural modelingBehavioral modelingMoving on to design
28
Chapter 2
29
Key IdeasAn 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
Key IdeasThe 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
IDENTIFYING PROJECTS IDENTIFYING PROJECTS WITH BUSINESS VALUEWITH BUSINESS VALUE
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.
System RequestA document describing business reasons for
project and system’s expected value.Lists project’s key elements
Project sponsorBusiness needBusiness requirementsBusiness valueSpecial issues or constraints
System Request ExamplesProject sponsor – VP of MarketingBusiness need – Reach new customers and
improve service to existing customersBusiness requirements – Provide web-based
shopping capabilityBusiness value - $750,000 in new customer
sales; $1.8M in existing customer salesSpecial issues or constraints – System must
be operational by holiday shopping season
Preliminary Project AcceptanceSystem request is reviewed by approval
committeeBased on information provided, project
merits are assessed.Worthy projects are accepted and undergo
additional investigation – the feasibility analysis.
Feasibility AnalysisDetailed business case for the project
Technical feasibilityEconomic feasibilityOrganizational feasibility
Compiled into a feasibility studyFeasibility is reassessed throughout the project
37
Technical Feasibility: Can We Build It?
Users’ and analysts’ familiarity with the business application area
Familiarity with technologyHave we used it before? How new is it?
Project sizeNumber of people, time, and features
Compatibility with existing systems
Economic Feasibility: Should We Build It?
Identify costs and benefitsAssign values to costs and benefitsDetermine cash flowAssess financial viability
Net present value (NPV)Return on investment (ROI)Break even point(BEP)
40
Costs Benefits
Tangible
Intangible
***
***
***
***
Assign Cost and Benefit ValuesDifficult, but essential to estimateWork with people who are most familiar with
the area to develop estimatesIntangibles should also be quantifiedIf intangibles cannot be quantified, list and
include as part of supporting material
Organizational Feasibility: If we build it, will they come?
Strategic alignmentHow well do the project goals align with
business objectives?Stakeholder analysis
Project champion(s)Organizational managementSystem users
Project SelectionApproval committee works from the system
request and the feasibility studyProject 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 portfolioViable projects may be rejected or deferred
because of project portfolio issues.
Chapter 3
44
Key DefinitionsProject 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
Four Key Steps in Managing Projects
Identifying project sizeCreating and managing the workplanStaffing the projectCoordinating and controlling project
activities
46
47
48
Project Management involvesmaking trade-offs…
Project Size
Pro
ject C
ost
Proj
ect Ti
me
Modifying one elementrequires adjusting the others
Project EstimationThe process of assigning projected values for
time and effortSources of estimates
Methodology in useActual previous projectsExperienced developers
Estimates begin as a range and become more specific as the project progresses
49
50
Planning Analysis Design Implementation
IndustryStandardFor Web 15% 20% 35% 30%Applications
TimeRequired 4 5.33 9.33 8in PersonMonths
Converting Function Points to Lines of Code
51
Source: Capers Jones, Software Productivity Research
Language LOC ratio
CCOBOLJAVAC++
Turbo PascalVisual BasicPowerBuilderHTMLPackages (e.g., Access, Excel)
130110 55 50 50 30 15 1510-40
52
53
Work Plan Information Example
Name of task Perform economic feasibilityStart date ` Jan 05, 2003Completion date Jan 19, 2003Person assigned Mary Smith, sponsorDeliverable(s) Cost-benefit analysisCompletion status OpenPriority HighResources needed SpreadsheetEstimated time 16 hoursActual time 14.5 hours
Identifying TasksMethodology
Using standard list of tasksTop-down approach
Identify highest level tasksBreak them into increasingly smaller unitsOrganize into work breakdown structure
54
Project WorkplanList of all tasks in the work breakdown
structure, plusDuration of taskCurrent task statusTask dependenciesKey milestone dates
55
Tracking Project TasksGantt Chart
Bar chart formatUseful to monitor project status at any point in
timePERT Chart
Flowchart formatIllustrate task dependencies and critical path
56
57
Go to Library
Go to Bookstore
Select and Purchase Book
Skim Book
Write Phase One
Read Book Carefully
Write Phase Two
Task Week 2 3 4 5 6 7 8 9 10 11 12 13
58
Go to Library4 weeks
Select and purchase book
1 weekGo to Bookstore4 weeks
Skim book3 weeks
Write Phase One2 weeks
Read book carefully3 weeks
Write Phase Two3 weeks
59
Staffing AttributesStaffing levels will change over a project’s
lifetimeAdding staff may add more overhead than
additional laborUsing teams of 8-10 reporting in a
hierarchical structure can reduce complexity
60
61
62
63
Planning Analysis Design Implementation
Upper CASE Lower CASE
Integrated CASE (I-CASE)
64
Procedural MetadataLogic
Diagrams ScreenDesigns
CASE Repository
StandardsExamples
Formal rules for naming filesForms indicating goals reachedProgramming guidelines
65
DocumentationProject binderTable of contentsContinual updating
66
Managing RiskRisk assessmentActions to reduce riskRevised assessment
67
Classic MistakesOverly optimistic scheduleFailing to monitor scheduleFailing to update scheduleAdding people to a late project
68
Chapter 4
69
Key DefinitionsThe As-Is system is the current system and
may or may not be computerizedThe To-Be system is the new system that is
based on updated requirementsThe System Proposal is the key deliverable
from the Analysis Phase
70
Key IdeasThe 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
What is a Requirement?A statement of what the system must do A statement of characteristics the system
must haveFocus is on business user needs during
analysis phaseRequirements will change over time as
project moves from analysis to design to implementation
72
Requirement TypesFunctional Requirements
A process the system hast to performInformation the system must contain
Nonfunctional RequirementsBehavioral properties the system must have
Operational Performance Security Cultural and political
73
Documenting RequirementsRequirements definition report
Text document listing requirements in outline form
Priorities may be includedKey purpose is to define the project scope:
what is and is not to be included.
74
Basic Steps of Determining Requirements
Understand the “As-Is” systemIdentify improvement opportunitiesDevelop the “To-Be” system conceptTechniques vary in amount of change
Business Process Automation (BPA) – small changeBusiness Process Improvement (BPI) - moderate change Business Process Reengineering (BPR) – significant
changeAdditional information gathering techniques are
needed as well
75
Chapter 5
76
Key IdeasFunctional 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
Elements of an Activity Diagram
Actions/ActivitiesObject NodesObject FlowsControl NodesControl FlowsSwimlanes
78
Activity Diagram
79
What are Use-Case Descriptions?
Describe basic functions of the system
What the user can doHow the system responds
Use cases are building blocks for continued design activities.
80
How Are Use-Cases Created?Two steps:
Write text-based case descriptionsTranslate descriptions into diagrams
Describes one and only one function, but may have multiple paths.
Developed working with users for content.
81
Types of Use-CasesOverview versus detailEssential versus real
82
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
85
Chapter 6
86
Key DefinitionsData 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
Key DefinitionsPhysical 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
What Is an ERD?A picture showing the information created,
stored, and used by a business system. Entities generally represent similar kinds of
informationLines drawn between entities show
relationships among the dataHigh level business rules are also shown
90
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 existA doctor must exist before appointments the
doctor can be made
91
ERD symbols can show when one instance of an entity can be related to only one or many instances of another entityOne doctor can have many patients; each
patient may have only one primary doctorERD symbols show when the existence of
an entity instance is optional for a related entity instanceA patient may or may not have insurance
coverage
92
93
EntityA person, place, event, or thing about
which data is collectedMust be multiple occurrences to be an
entityExample: 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
AttributesInformation captured about an entityOnly those used by the organization should
be included in the modelAttribute names are nounsSometimes entity name is added at the
beginning of the attribute name for clarity
96
IdentifiersOne 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
RelationshipsAssociations between entitiesThe first entity in the relationship is the
parent entity; the second entity in the relationship is the child entity
Relationships should have active verb namesRelationships go in both directions
99
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
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
ERD BasicsDrawing the ERD is an iterative process of
trial and revisionERDs can become quite complex
103
Steps in Building ERDsIdentify the entitiesAdd appropriate attributes for each entityDraw the relationships that connect
associated entities
104
Identify the EntitiesIdentify 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
Add Appropriate AttributesIdentify attributes of the entity that are relevant
to the system under developmentCheck the process model repository entries for
details on data flows and data storesCheck the data requirements of the requirements
definitionInterview knowledgeable usersPerform document analysis on existing forms and
reportsSelect the entity’s identifier
106
Draw the RelationshipsStart with an entity and identify all
entities with which it shares relationshipsDescribe the relationship with the
appropriate verb phraseDetermine the cardinality and modality by
discussing the business rules with knowledgeable users
107
ERD Building TipsOnly include entities with more than one
instance of informationDon’t include entities associated with
implementation of the system (they will be added later)
108
109
110
Best practices rather than rulesEntities should have many occurrencesAvoid unnecessary attributesClearly label all components Apply correct cardinality and modalityBreak attributes into lowest level neededLabels should reflect common business
termsAssumptions should be clearly stated
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
Chapter 7
113
Key IdeasA 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
Purpose of Structural ModelsReduce the “semantic gap” between the
real world and the world of softwareCreate a vocabulary for analysts and
usersRepresent things, ideas, and concepts of
importance in the application domain
115
ClassesTemplates for creating instances or
objectsConcreteAbstract
Typical examples:Application domain, user interface,
data structure, file structure, operating environment, document, and multimedia classes
116
AttributesUnits of information relevant to the
description of the classOnly attributes important to the task should
be included
117
OperationsAction that instances/objects can takeFocus on relevant problem-specific
operations (at this point)
118
RelationshipsGeneralization
Enables inheritance of attributes and operations
AggregationRelates parts to wholes
AssociationMiscellaneous relationships between classes
119
120
121
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____
More on AttributesDerived attributes
/age, for example can be calculated from birth date and current date
VisibilityPublicProtectedPrivate
123
More on OperationsConstructor
Creates objectQuery
Makes information about state availableUpdate
Changes values of some or all attributes
124
More on RelationshipsClass 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
Simplifying Class DiagramsThe view mechanism shows a subset of
informationPackages show aggregations of classes (or
any elements in UML)
126
127
Object IdentificationTextual analysis of use-case information
Nouns suggest classesVerbs suggest operations
Creates a rough first cutCommon object listIncidentsRoles
128
PatternsUseful groupings of classes that recur in
various situationsTransactions
Transaction classTransaction line item classItem classLocation classParticipant class
129
Chapter 8
130
Key IdeasBehavioral 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
Purpose of Behavioral ModelsTo depict the internal view of business
processesTo show the effects of varied processes on
the system
132
Interaction Diagram Components
ObjectsOperationsMessages
133
Sequence DiagramsIllustrate the objects that participate in a use-
caseShow the messages that pass between
objects for a particular use-case
134
135
136
AN ACTOR
AN OBJECT
A LIFELINE
A FOCUS OF CONTROL
A MESSAGE
OBJECT DESTRUCTION
anObject:aClass
aMessage()
x
137
Determine the context of the sequence diagram
Identify the participating objectsSet the lifeline for each objectAdd messagesPlace the focus of control on each object’s
lifelineValidate the sequence diagram
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
Chapter 9
140
Key DefinitionsThe navigation mechanism provides the way for
users to tell the system what to doThe input mechanism defines the way the system
captures informationThe output mechanism defines the way the
system provides information to users or other systems
141
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
Basic PrinciplesAssume users
Have not read the manualHave not attended trainingDo not have external help readily at hand
All controls should be clear and understandable and placed in an intuitive location on the screen.
144
Basic PrinciplesPrevent mistakes
Limit choicesNever display commands that can’t be used (or
“gray them out”)Confirm actions that are difficult or impossible
to undoSimplify recover from mistakesUse consistent grammar order
145
Types of Navigation ControlLanguages
Command languageNatural language
MenusGenerally aim at broad shallow menuConsider using “hot keys”
Direct ManipulationUsed with icons to start programsUsed to shape and size objectsMay not be intuitive for all commands
146
147
148
149
150
Types of Menus
Menu barDrop-down menuPop-up menuTab menuToolbarImage map
WhenWould YouUse Each ofThese MenuTypes?
Message TipsShould be clear, concise, and completeShould be grammatically correct and free of
jargon and abbreviations (unless they are the users)
Avoid negatives and humor
151
152
Types of Messages
Error messageConfirmation messageAcknowledgment messageDelay messageHelp message
WhenWould YouUse Each ofThese MessageTypes?
153
154
Basic PrinciplesThe goal is to simply and easily capture
accurate information for the systemReflect the nature of the inputsFind ways to simplify their collection
155
Online versus Batch ProcessingOnline processing immediately records the
transaction in the appropriate databaseBatch 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
Capture Data at the SourceReduces duplicate workReduces processing timeDecreases costDecreases probability of error
157
Source Data AutomationCan be obtained by using the following
technologies:bar code readersoptical character recognitionmagnetic stripe readerssmart cards
How can internet be used for source data automation?
158
Minimize KeystrokesNever ask for information that can be
obtained in another wayList selection is more efficient than entering
informationUse default values where possible
159
Types of InputsData items linked to fieldsTextNumbersSelection boxes
160
161
162
Types of Boxes
Check boxRadio buttonOn-screen list boxDrop-down list boxCombo boxSlider
WhenWould YouUse Each ofThese BoxTypes?
163
Types of Validation
Completeness checkFormat checkRange checkCheck digit checkConsistency checkDatabase checks
WhenWould YouUse Each ofThese ValidationMethods?
164
Basic PrinciplesUnderstand report usage
Reference or cover-to-cover?Frequency?Real-time or batch reports?
Manage information loadAll needed information, no more
Minimize bias
165
166
Types of Reports
Detail reportsSummary reportTurnaround documentGraphs
WhenWould YouUse Each ofThese ReportTypes?
167
Electronic
Versus Paper