2006 tutorial sad
TRANSCRIPT
-
8/8/2019 2006 Tutorial SAD
1/57
SEG3560 Introduction toE-Commerce
Tutorial 3 System Analysis & Design
GAO Wei, Rm711, ERBII, Email:[email protected]
-
8/8/2019 2006 Tutorial SAD
2/57
Outline
Overview of SDLC
project phases
Process Modeling
context diagram, data flow diagrams Architecture Design
tiered architectures, nonfunctional
requirements
-
8/8/2019 2006 Tutorial SAD
3/57
PART I: Overview of SDLC
-
8/8/2019 2006 Tutorial SAD
4/57
Key Ideas Many failed systems were abandoned because
analysts tried to build wonderful systems without
understanding the organization. The primary goal is to create value for the
organization.
The systems analyst is a key person analyzingthe business, identifying opportunities forimprovement, and designing information systems
to implement these ideas. It is important to understand and develop throughpractice the skills needed to successfully designand implement new information systems.
-
8/8/2019 2006 Tutorial SAD
5/57
The Systems Development LifeCycle (SDLC)
The project --
Moves systematically through phases where each phase has astandard set of outputs
Produces project deliverables Uses deliverables in implementation Results in actual information system
Uses gradual refinement
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)
-
8/8/2019 2006 Tutorial SAD
6/57
Planning Identifying business value Gain an appropriate understanding of the business problem domain Estimate the investment and reward on the project
e.g. the percentage of cost reduction paid in warehousing Analyze feasibility
Technical, economical and organizational Analyzes the information needs of the end users e.g. co-ordination among sales, warehouse keeper, merchandiser
or more parties
Develop work plan Decide the sequence of process completion PERT Chart
Staff the project Control and direct project
Prioritize - requirements can be classified as mandatory, desirable,or optional.
-
8/8/2019 2006 Tutorial SAD
7/57
Analysis Analysis strategy
As-is system and to-be system Iterative cycle of steps until they are considered accurate and complete e.g. integration of old and future system
Gathering business requirements Requirements definition use cases
Specify these requirements without expressing computer alternatives andtechnology details; at this point, keep analysis at the business level.
Process modeling Representing how business operates
Data flow diagram (DFD) e.g. Data flow for the login system
Data modeling
Balance with process models Entity-Relationship Diagram (ER diagram)
e.g. Relationship between attributes for warehouse keeper andmerchandiser
-
8/8/2019 2006 Tutorial SAD
8/57
Design Design selection transform the business requirements from the definition phase into
a set of technical design blueprints for construction
e.g. Microsoft .NET framework or J2EE Architecture design
specifications for the hardware, software, network infrastructureand data resources
detailed structure for N-tiers system
Interface design specifies how the users will move through the system,
navigation methods (menus, buttons, etc.), forms, reports.
Data storage design
defines what and how data will be stored. RDBMS, XML, raw textfile, etc.
Program design defines programs to be written, what each program will do.
-
8/8/2019 2006 Tutorial SAD
9/57
Implementation Construction
Program building creates and programs the final system
Program and system testing evaluates the system's actual functionality in relation to
expected or intended functionality Done systematically and results documented carefully
Avoid patches delivery after software release
Installation Conversion strategy
Direct, parallel or pilot conversion
Training plan Helping users accomplish their tasks
Support plan On-demand training , online support or helpdesk
-
8/8/2019 2006 Tutorial SAD
10/57
Processes and Deliverables
P ro cess P ro duct
Planning
Analysis
Design
Implementation
System RequestFeasibility Analysis
Workplan
System Proposal
System
Specification
New System andMaintenance Plan
-
8/8/2019 2006 Tutorial SAD
11/57
Waterfall DevelopmentMethodology
-
8/8/2019 2006 Tutorial SAD
12/57
Pros and Cons of the
Waterfall Methodology
P r o s Cons
Identifies systemsrequirements longbefore programmingbegins
Minimizes changes torequirements as
project progresses
Design must bespecified on paper
before programmingbegins
Long time betweensystem proposal anddelivery of newsystem
-
8/8/2019 2006 Tutorial SAD
13/57
Parallel DevelopmentMethodology
-
8/8/2019 2006 Tutorial SAD
14/57
Pros and Cons of Parallel
Development Methodology
P r o s Cons
Reduces Schedule
Time
Less Chance ofRework
Still Uses Paper
Documents
Sub-projects May BeDifficult to Integrate
-
8/8/2019 2006 Tutorial SAD
15/57
Phased Development Methodology
-
8/8/2019 2006 Tutorial SAD
16/57
Pros and Cons of Phased
Development Methodology
P r o s Cons
Users Get a System
To Use Quickly
Users Can IdentifyAdditional Needs
For Later Versions
Users Work with aSystem that isIntentionallyIncomplete
-
8/8/2019 2006 Tutorial SAD
17/57
Prototyping Methodology
-
8/8/2019 2006 Tutorial SAD
18/57
Pros and Cons of PrototypingMethodology
P r o s Cons
Users Interact withPrototype Very Quickly
Users Can IdentifyNeeded ChangesAnd Refine RealRequirements
Tendency to doSuperficial Analysis
Initial DesignDecisions May
Be Poor
-
8/8/2019 2006 Tutorial SAD
19/57
Throwaway Prototyping
-
8/8/2019 2006 Tutorial SAD
20/57
Pros and Cons of ThrowawayPrototyping Methodology
P r o s Cons
Risks are Minimized
Important Issues areUnderstood Before the
Real System is Built
May Take LongerThan Prototyping
-
8/8/2019 2006 Tutorial SAD
21/57
Agile Development: ExtremeProgramming
-
8/8/2019 2006 Tutorial SAD
22/57
Pros and Cons of Agile
Methodologies
P r o s Cons
Fast Delivery of Results
Works Well in ProjectsWith Undefined or
Changing Requirements
Requires Discipline
Works Best inSmall Projects
Requires MuchUser Input
-
8/8/2019 2006 Tutorial SAD
23/57
PART II: Process Modeling
-
8/8/2019 2006 Tutorial SAD
24/57
Process Modeling Process model
A formal way of representing how a businessoperates Illustrates the activities that are performed and how
data moves among them
Data flow diagram (DFD) A popular technique for creating process modelsLogicalprocess models describe processes without
suggesting how they are conducted (You need to do
in project phase 1!)Physicalprocess models include processimplementation information
-
8/8/2019 2006 Tutorial SAD
25/57
Reading a DFD
Process
Data flow
Data store
External
entity
-
8/8/2019 2006 Tutorial SAD
26/57
DFD Elements Process
An activity or function performed for a specificbusiness reason
Manual or computerized
Data flow A single piece of data or a logical collection of
data
Always starts or ends at a process
-
8/8/2019 2006 Tutorial SAD
27/57
DFD Elements Data Store
A collection of data that is stored in some way
Data flowing out is retrieved from the datastore
Data flowing in updates or is added to the datastore
External entity
A person, organization, or system that isexternal to the system but interacts with it.
-
8/8/2019 2006 Tutorial SAD
28/57
Naming and Drawing DFD
Elements
Process
Data flow
Data store
External
entity
-
8/8/2019 2006 Tutorial SAD
29/57
Depicting Business Processes
with DFDs Business processes are too complex to be
shown on a single DFD Decompositionis the process of representing
the system in a hierarchy of DFD diagrams
Child diagrams show a portion of the parent diagramin greater detail
Balancinginvolves insuring that information
presented at one level of a DFD is accuratelyrepresented in the next level DFD.
-
8/8/2019 2006 Tutorial SAD
30/57
Relationship Among DFD levels
Context diagram
Level 0 diagram
Level 1 diagram
Level 2 diagram
-
8/8/2019 2006 Tutorial SAD
31/57
Context Diagram First DFD in every business process
Shows the context into which the businessprocess fits
Shows the overall business process as just
oneprocess (process 0)
Shows all the external entities that receiveinformation from or contribute information to
the system
-
8/8/2019 2006 Tutorial SAD
32/57
Level 0 Diagram Shows all the major processes that comprise
the overall system the internal components ofprocess 0
Shows how the major processes are
interrelated by data flows Shows external entities and the major
processes with which they interact
Adds data stores
-
8/8/2019 2006 Tutorial SAD
33/57
Level 1 Diagrams Generally, one level 1 diagram is created for every
major process on the level 0 diagram Shows all the internal processes that comprise a single
process on the level 0 diagram
Shows how information moves from and to each ofthese processes
If a parent process is decomposed into, for example,three child processes, these three child processes
wholly and completely make up the parent process
-
8/8/2019 2006 Tutorial SAD
34/57
Level 2 Diagrams Shows all processes that comprise a single process on
the level 1 diagram Shows how information moves from and to each of
these processes
Level 2 diagrams may not be needed for all level 1processes
Correctly numbering each process helps the userunderstand where the process fits into the overall
system
-
8/8/2019 2006 Tutorial SAD
35/57
Example: Problem Description When a student wants to enroll in a course, he makes a class
request to the enrollment department. There are 3 officers in theenrollment department. After receiving the request, one officer enrollthe student in the course (details of enrollment are described in thenext paragraph) and store the student and course data into astudent-class file. Another one is responsible for collecting studentfee payment, issuing receipts and handling payment information of astudent payments file. There is one more officer producing different
reports to different people. He will produce a student schedule to thestudent who has been enrolled in a course, produce a class roster tothe corresponding professor, and produce enrollment statistics toregister.
After a student has raised a request, the officer needs to check for anopen section from a classes offered file. If a section is available, hewill check prerequisites of the student by referring the student masterfile and course master file. After this checking is completed, he helpsthe student enrolling in the course by updating the classes offered
file and the student class file.
-
8/8/2019 2006 Tutorial SAD
36/57
Context Diagram
Student
Professor
CourseEnrollmentSystem Registrar
Class Request /Payment
Student Schedule /Receipt
ClassRoster
Enrollment
Statistics
-
8/8/2019 2006 Tutorial SAD
37/57
Level 0: The course enrollment system
1.0EnrollStudentin Class
2.0Collect
Student FeePayement
3.0Produce
StudentSchedule
4.0ProduceClassRoster
5.0Produce
EnrollmentSummaryReport
Student Student
Professor Registrar
Student ClassRecord
Student
Payments
PaymentReceipt
PaymentInformation
StudentClassRecord
StudentClassRecord
StudentSchedule
EnrollmentStatistics
StudentClassRecord
StudentClassRecord
ClassRoster
Student andCourse Data
ClassRequest
-
8/8/2019 2006 Tutorial SAD
38/57
Level 1: Process 1.0 -- Enroll student in
class
ClassesOffered
StudentMaster
CourseMaster
StudentClass Record
1.1Check for
an opensection
1.2CheckPre-requisitesmet
1.3Enroll
studentin class
Student
ClassRequest
OpeningsRemaining
OpeningsRemainingStudentCourseRecord
ValidClass Request
Open ClassRequest
StudentRecord
CourseRecord
-
8/8/2019 2006 Tutorial SAD
39/57
PART III: Architecture Design
-
8/8/2019 2006 Tutorial SAD
40/57
Architecture Design -- Key
Definitions
Architecture design
Plans for how the system will be distributedacross computers and what the hardware andsoftware will be used for each computer
Hardware and software specification Describes the hardware/software components
in detail to aid those responsible for
purchasing those products.
Architect ral Components
-
8/8/2019 2006 Tutorial SAD
41/57
Architectural Components
(Functions) of Software Data storage
Data access logic
Processing required to access stored data
Application logic Processing logic of the application
Presentation logic
Information display and user commandprocessing
-
8/8/2019 2006 Tutorial SAD
42/57
Architectural Design Purpose
Determine what parts of the application software will beassigned to what hardware.
Hardware options:
Clients Input/output devices employed by users PCs, laptops, handheld devices, cell phones
Servers Larger computers storing software
Accessible by many users Alternative Servers
Mainframe Minicomputer Microcomputer (personal computer)
Alternative Clients Terminals Microcomputer (personal computer) Special purpose terminals (ATMs, Palm Pilots, and many others)
-
8/8/2019 2006 Tutorial SAD
43/57
Architecture Choices Server-based Architecture
Client-based Architecture
Client-server based Architecture
-
8/8/2019 2006 Tutorial SAD
44/57
Server-Based Architecture
-
8/8/2019 2006 Tutorial SAD
45/57
Client-Based Architecture
C S
-
8/8/2019 2006 Tutorial SAD
46/57
Two-Tiered Client-Server Architecture
(Thick Client-Server)
-
8/8/2019 2006 Tutorial SAD
47/57
Client-Server Attributes Benefits
Scalable Works with multiple
vendors/productsthrough middleware
Improved modularityof web-basedsystems
No central point offailure
Limitations
Complexity New programming
languages andtechniques (addsstress for personnel)
More complex toupdate
Three Tiered Client Server Architecture
-
8/8/2019 2006 Tutorial SAD
48/57
Three-Tiered Client-Server Architecture
(Thin Client-Server)
Four-Tiered Client-Server
-
8/8/2019 2006 Tutorial SAD
49/57
Four-Tiered Client-Server
Architecture
N Ti d 2 Ti d
-
8/8/2019 2006 Tutorial SAD
50/57
N-Tiered versus 2-TieredClient-Server Architectures
Benefits
Separates processingto better balance loadon different servers
More scalable
Limitations
Greater load on thenetwork
More difficult to
program and test
-
8/8/2019 2006 Tutorial SAD
51/57
Selecting an Architecture Design Lower costs often used to justify choice of
client-server Recommended selection process:
Expand nonfunctional requirement details
Base architecture selection on the detailednonfunctional requirements
-
8/8/2019 2006 Tutorial SAD
52/57
Operational Requirements
The system mustaccommodate newmanufacturing plants
Expected business changesto which the system shouldbe able to adapt
Maintainability
The system may need tooperate with handhelddevices
The extent to which thesystem will need to operatein other environments
Portability
The system will read andwrite to the main inventory
database
The extent to which thesystem will operate with
other systems
SystemIntegration
Always-on networkconnection permitting real-time database updates
Special hardware, software,and network requirementsimposed by businessrequirements
TechnicalEnvironment
ExampleDefinitionRequirement
-
8/8/2019 2006 Tutorial SAD
53/57
Performance Requirements
99% uptime performanceExtent to which the system willbe available to the users and thepermissible failure rate due toerrors
Availability andReliability
Maximum of 100-200simultaneous users at
peak times
Total and peak number of usersand the volume of data expected
Capacity
Network transactionresponse time
-
8/8/2019 2006 Tutorial SAD
54/57
Security Requirements
All uploaded files will bechecked for viruses beforebeing saved in the system
Controls to limit virusesVirus Control
Data will be encrypted fromthe users computer to theWeb site to provide secureordering
Defines what data will beencrypted where andwhether authentication willbe needed for user access
Encryption andAuthentication
Inventory changes can bemade only by departmentmanagers
Limitations on who canaccess what data
Access Control
A complete loss of allsystem data would cost $20million
Estimated business value ofthe system and its dataSystem ValueEstimates
ExampleDefinitionRequirement
-
8/8/2019 2006 Tutorial SAD
55/57
Cultural/Political Requirements
Personal customer information
cannot be transferred fromEuropean Union countries to US
The laws and regulations
that impose systemrequirements
Legal
All weights will be stated inkilograms
Explicitly statingassumptions that differfrom country to country
MakingUnstatedNorms Explicit
Country managers will be able todefine new fields in the productdatabase to capture country-
specific information
Specification of whataspects of the systemcan be changed by local
users
Customization
The system will operate inEnglish, French, and SpanishThe language(s) thesystem users will needMultilingual
ExampleDefinitionRequirement
Nonfunctional Requirements
-
8/8/2019 2006 Tutorial SAD
56/57
o u ct o a equ e e ts
and the Architecture Design
-
8/8/2019 2006 Tutorial SAD
57/57
References Systems Analysis and Design, 2nd Edition
by Alan Dennis and Barbara Haley Wixom,published by John Wiley's & Sons Inc.,2003. Ch1,5,9.
System Analysis and Design Methods, 6thEditionby Jeffrey L. Whitten, Lonnie D. Bentley
and Kevin Dittman, published by IrwinMcGraw-Hill.