2006 Tutorial SAD

8/8/2019 2006 Tutorial SAD

1/57

SEG3560 Introduction toE-Commerce

Tutorial 3 System Analysis & Design

GAO Wei, Rm711, ERBII, Email:[email protected]


2/57

Outline

Overview of SDLC

project phases

Process Modeling

context diagram, data flow diagrams Architecture Design

tiered architectures, nonfunctional

requirements


3/57

PART I: Overview of SDLC


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.


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)


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.


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/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.


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


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


11/57

Waterfall DevelopmentMethodology


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


13/57

Parallel DevelopmentMethodology


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


15/57

Phased Development Methodology


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


17/57

Prototyping Methodology


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


19/57

Throwaway Prototyping


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


21/57

Agile Development: ExtremeProgramming


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


23/57

PART II: Process Modeling


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


25/57

Reading a DFD

Process

Data flow

Data store

External

entity


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


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.


28/57

Naming and Drawing DFD

Elements

Process

Data flow

Data store

External

entity


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.


30/57

Relationship Among DFD levels

Context diagram

Level 0 diagram

Level 1 diagram

Level 2 diagram


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


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


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


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


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.


36/57

Context Diagram

Student

Professor

CourseEnrollmentSystem Registrar

Class Request /Payment

Student Schedule /Receipt

ClassRoster

Enrollment

Statistics


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


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


39/57

PART III: Architecture Design


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


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


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)


43/57

Architecture Choices Server-based Architecture

Client-based Architecture

Client-server based Architecture


44/57

Server-Based Architecture


45/57

Client-Based Architecture

C S


46/57

Two-Tiered Client-Server Architecture

(Thick Client-Server)


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


48/57

Three-Tiered Client-Server Architecture

(Thin Client-Server)

Four-Tiered Client-Server


49/57

Four-Tiered Client-Server

Architecture

N Ti d 2 Ti d


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


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


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


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


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



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


Nonfunctional Requirements


56/57

o u ct o a equ e e ts

and the Architecture Design


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.