Transcript Introduction to Information Systems Analysis Systems Design Application Architecture & Modeling INFO 503 Glenn Booker INFO 503 Lecture #5

Introduction to Information
Systems Analysis
Systems Design
Application Architecture & Modeling
INFO 503
Glenn Booker
INFO 503
Lecture #5
1
System Design
• System Design (a.k.a. physical design)
includes the evaluation of alternative
solutions, and specification of a
detailed solution
• Focus is the shift from logical to physical
design; now technology counts!
• Critical to consider off-the-shelf options
INFO 503
Lecture #5
2
Design Strategies
•
•
•
•
•
•
Modern structured design
Information engineering
Prototyping
Object-Oriented Design (OOD)
Joint Application Development (JAD)
Rapid Application Development (RAD)
INFO 503
Lecture #5
3
Modern Structured Design
• A.k.a. top-down program design and
structured programming
• Is a process-oriented technique to break a
program into smaller pieces (modules) by
using certain rules and guidelines
• Each module is a set of instructions to
perform a specific function
INFO 503
Lecture #5
4
Modern Structured Design
• Modules should be cohesive - perform only
one function; this helps reusability too
• Modules should be loosely coupled - have
minimal interaction or dependency on
each other
• Capture design in a structure chart,
p. 474 (314)
• Not event driven or object-oriented
INFO 503
Lecture #5
5
Information Engineering
• Analysis was based on defining applications
to support the requirements of various
business areas
• IE does not have its own unique design
technique; tools such as the ERD are the
starting point
– Address process issues later
INFO 503
Lecture #5
6
Prototyping
• Developing prototypes:
–
–
–
–
–
INFO 503
Encourages end user involvement
Is well suited to iterative development
Allows hands-on verification of requirements
Provides quick feedback
Often speeds several life cycle phases
Lecture #5
7
Prototyping
• But prototyping:
– Encourages irresponsible code-and-fix
life cycle
– Can only augment paper specifications
and other design techniques
– Omits several design issues; storage,
control, performance
INFO 503
Lecture #5
8
Prototyping
• And prototyping:
– Can lead to premature design commitment
(lock in design options)
– Can reduce creativity
– Can lead to feature (scope) creep
– Can result in slower performance
INFO 503
Lecture #5
9
Object-Oriented Design
• OOD uses the results of OOA to design
objects which will implement the system
• Addresses data and process issues at the
same time
• Can, for example, focus on defining objects,
and then defining the methods which
communicate between them, p. 478 (546)
INFO 503
Lecture #5
10
Joint Application Development
• JAD can be used for participative
development of a design, in conjunction
with other design techniques
INFO 503
Lecture #5
11
Rapid Application Development
• RAD blends other design techniques
(structured design, information
engineering, prototyping and JAD) to
speed system development
• Often based on using specific tools which
support the process
INFO 503
Lecture #5
12
FAST Design Methodology
• Design covers the following FAST phases:
– Decision Analysis (Configuration) Phase,
from Chapter 5 in the 6th edition
– Procurement Phase (not a separate phase,
it is addressed during System Design phase
in the 6th edition)
– Physical Design and Integration Phase,
this is detailed design before construction
of the system
INFO 503
Lecture #5
13
Decision Analysis
(Configuration) Phase
• The decision analysis phase identifies
candidate configurations, and picks the best
• Activities are:
–
–
–
–
–
INFO 503
5.1 Identify Candidate Solutions
5.2 Analyze Candidate Solutions
5.3 Compare Candidate Solutions
5.4 Update the Project Plan
5.5 Recommend a System Solution
Lecture #5
14
Identify Candidate Solutions
• This activity identifies the candidate system
design solutions, based on business needs
and possible implementation technology
• Ideas may come from system owners, users,
and others involved in the analysis effort
• Candidates may be based on the technology
architecture of your organization
INFO 503
Lecture #5
15
Identify Candidate Solutions
• Activity consists largely of brainstorming
for ideas, followed by research to assess
their characteristics
• Do not judge the solutions - yet
• Output is a table to describe possible
solutions, p. 221 (322), the Candidate
Systems Matrix
INFO 503
Lecture #5
16
Analyze Candidate Solutions
• Now assess each candidate solution for:
–
–
–
–
Technical feasibility (practical and staffable)
Operational feasibility (effect on users)
Economic feasibility (is it cost effective?)
Schedule feasibility (can it be done on time?)
• Need to define hardware, training, and
software costs for each solution
• Output: feasibility assessment, p. 223 (324)
INFO 503
Lecture #5
17
Compare Candidate Solutions
• Based on the relative importance of the
feasibility criteria (i.e. their weight in %),
score each of the candidate solutions
– Weighting of feasibility criteria often done by
the system owner
– Throw out infeasible solutions (those which
are impossible)
• Pick the best solution!
INFO 503
Lecture #5
18
Update the Project Plan
Does this task seem familiar yet?
• Update the project plan to reflect the chosen
system configuration
• Reevaluate scope and tasks as needed
INFO 503
Lecture #5
19
Recommend a System Solution
• Now use the updated project plan to
recommend a solution to the system owner,
with other key interested parties present
– Might give recommendations (the system
proposal) verbally or in writing
– Salesmanship is often helpful to pitch
the solution
• Hopefully ends with approval to continue
INFO 503
Lecture #5
20
Procurement Phase
p. 487
(326)
• The procurement phase is to assess off-theshelf options for supporting system design
• This phase is a blend of two new tasks for
the “Procurement phase,” and three revised
tasks for the “Decision Analysis phase”
– Task numbering in the 6th edition looks weird;
it’s intended to replace the specified steps in
phases 4 and 5, respectively
INFO 503
Lecture #5
21
Procurement Phase
• New tasks for the Procurement phase are:
– 4.1 Research Technical Criteria and Options
– 4.2 Solicit Proposals from Vendors
• Revised Decision Analysis phase tasks:
– 5A.1 Validate Vendor Claims and Performance
– 5A.2 Evaluate and Rank Vendor Proposals
– 5A.3 Award Contract and Debrief Vendors
INFO 503
Lecture #5
22
Research Technical
Criteria and Options
• Identify specifications for hardware
and software - functions, features, and
critical performance needs - based on
the system requirements
– May be based on internal standards, and
research of trade journals and magazines
• Use to define technical criteria, product
options, and potential vendors
INFO 503
Lecture #5
23
Solicit Proposals from Vendors
• Based on the technical criteria, prepare a
request for quotation (RFQ) or a
request for proposal (RFP)
– An RFQ is used for a predefined product
– Use an RFP when the product is ill defined
• The RFQ/RFP must define the selection
criteria, and classify requirements as
mandatory, essential, or optional
INFO 503
Lecture #5
24
Validate Vendor Claims
and Performance
• Proposals from prospective vendors must be
validated to ensure their individual merits
– For major software proposals, a Software
Capability Evaluation (SCE) may be used
• Validation may be through site visits,
contacting other clients, and other research
• Results in validated or invalidated proposals
– ‘Invalidated’ means you don’t believe them
INFO 503
Lecture #5
25
Evaluate and Rank
Vendor Proposals
• Throw out all invalidated proposals
• Validated proposals can now be evaluated
and ranked, using the predefined criteria
– This is a form of feasibility assessment, but it
might include criteria about the stability of the
vendor, or their level of support
• Results in a recommendation to use a
particular vendor (we hope)
INFO 503
Lecture #5
26
Award Contract and
Debrief Vendors
• The vendor selection is approved by
management or the system owner
• Contracts are prepared, negotiated,
and reviewed by winning vendor and
system owner
• All candidate vendors are briefed on the
results of the evaluation (if you’re nice)
• Update affected interface requirements
INFO 503
Lecture #5
27
Physical Design & Integration Phase
• This phase bridges the gulf between the user
requirements and the builders’ input needs
–
–
–
–
–
INFO 503
6.1 Design the Application Architecture
6.2 Design the System Database
6.3 Design the System Interface
6.4 Package Design Specifications
6.5 Update Project Plan
Lecture #5
28
Design the Application
Architecture
• Defines technologies used by the system,
including data, process, interface, and
network components
• How will data, process, and interface be
distributed across locations?
– Based on data and process models
• Might include physical data flow diagram,
p. 482 (373)
INFO 503
Lecture #5
29
Design the System Database
• System database(s) are designed in more
detail – allowing not only for full 3NF,
but also addressing performance, design
flexibility, storage, security, record size,
and backup/recovery needs
• Capture in a database schema (often ERD)
INFO 503
Lecture #5
30
Design the System Interface
• Design the user interfaces to the system –
inputs and outputs
• Design preprinted forms and reports
• Lots of existing user input is helpful!
• Consider ease of learning, as well as use
• Define controls to help get complete and
correct data (minimize input errors)
INFO 503
Lecture #5
31
Package Design Specifications
• Take the results of the previous three
steps and put it into a design specification
document – essentially a blueprint to guide
the system builders
• Need to balance how much design must be
specified for the builders, and how much
can be left to their discretion and creativity
• Review with all affected parties
INFO 503
Lecture #5
32
Update Project Plan
Mary had a little lamb
Whose fleece was white as snow
And everywhere that Mary went
She updated the project plan
to reflect her progress
• Update the project plan, now that full
design information is available (last sanity
check before the start of construction!)
INFO 503
Lecture #5
33
Application Architecture
• Return to general design focus, not detailed
• Application architecture addresses general
system design and technology issues:
–
–
–
–
INFO 503
How distributed is computing (processing)?
How distributed is data storage?
Make or buy technology?
Which technologies are used for user and
system interfaces, and for programming?
Lecture #5
34
Modeling Application
Architecture
• Application architectures can be captured
in many ways
• A physical data flow diagram (PDFD) can
show the technical design, such as the
software or people involved in each process
– Physical data flows can identify both the name
of each data flow, and how it is implemented
(person’s role, bar code, HTML, VB, etc.)
INFO 503
Lecture #5
35
Modeling Application
Architecture
p. 504
(373)
• Physical data flows expand on the logical
model; may also show user vs machine lines
• Physical data flows may include:
–
–
–
–
INFO 503
Input or output to/from a process
Database commands (CRUD) with data stores
Import or export of data from another system
Flow of data between two modules or
subsystems within your system
Lecture #5
36
Modeling Application
Architecture
• Physical data stores might include:
– An entire database
– A table in a database
– A file on the computer (whether temporary
or permanent)
– A tape backup device
– Any other kind of file, paper, or form
INFO 503
Lecture #5
37
Modeling Application
Architecture
• A network topology data flow diagram
can show which processors or people
support various processes
• System flowcharts were popular for
showing all programs, inputs, outputs,
data, and processes at once - whew!
• CASE tools can automate generation
of flowcharts and DFDs
INFO 503
Lecture #5
38
IT Architecture
• IT architecture is evolving rapidly; stay
tuned for current events! (see SEI, ACM)
• Networking architecture issues drive many
others, so look at them first
– Historic footnote: early PCs weren’t designed
for multiple users or local networks
• Wireless communications emerging as
newest key factor in networking
INFO 503
Lecture #5
39
Five Application Layers
• Presentation layer is what the user sees
• Presentation logic layer determines what
needs to be displayed on the screen
• Application logic layer controls how the
application runs
• Data manipulation layer controls getting
data, which lives in the data layer
INFO 503
Lecture #5
40
IT Architecture
• Architecture options range from centralized
to distributed in varying degrees
– Purely centralized computing was the
mainframe philosophy (one box does it all)
– Web-based systems are the most decentralized
• “Servers” are computers shared by many
users at once
• “Clients” are used by one user at a time
INFO 503
Lecture #5
41
IT Architecture
• Servers might fulfill many purposes
– File servers hold data files used by many users
– Database servers run the database program and
store its data
– Application servers get data inputs from the
clients, and get data from the database server
– Web servers host a web site, and communicate
among clients and application servers
INFO 503
Lecture #5
42
IT Architecture
• Clients can be ‘fat’ or ‘thin’
– Fat clients have a custom application installed
to communicate with the servers (now rare)
• If you had to install a special program to use that
system, you are probably using a fat client
– Thin clients communicate with the servers
through an ordinary (not customized) program,
such as a web browser (now common)
• Thin clients act like a dumb terminal
INFO 503
Lecture #5
43
IT Architecture
• Architecture options (see p. 511 (355)) are:
–
–
–
–
–
–
INFO 503
Centralized computing (not shown)
File server architecture
Distributed presentation (2 tier)
Distributed data (2 tier)
Distributed data & application (n tier)
Network computing (web)
Lecture #5
44
Centralized Computing
• Centralized computing was the only
architecture approach through the 1970’s
• Used a mainframe or minicomputer to do
all the work, accessed through terminals
– VT100 or IBM 3270 terminals; really dumb
clients, they only displayed what text the
mainframe sent to them
• Very few systems still use this
INFO 503
Lecture #5
45
File Server Architecture
• This primitive form of distributed
computing stores data on a file server, and
everything else is done by the clients
• The file server just holds the shared data
files and lets the clients read it or write to
it when needed
• Is a common cheap way to share data
across a local area network (LAN)
INFO 503
Lecture #5
46
Client/server Architecture
• Client/server architecture (distributed or
cooperative computing) is the dominant
network architecture starting in the 1980’s
• Data, software, and interfaces may be
distributed across many clients and servers
– ‘Distributed presentation’, ‘distributed data’,
and ‘distributed data and application’ structures
are all types of client/server architecture
INFO 503
Lecture #5
47
Server Types
• Client/server may use many server types
– Database server for data and data manipulation
– Transaction server to control groups of business
transactions together
– Application server for the same layer
– Messaging or groupware for Notes or Exchange
– Web server for hosting Internet or Intranet sites
INFO 503
Lecture #5
48
Distributed Presentation
• Distributed presentation (a.k.a. chintzy
client/server) puts a pretty GUI on what
were text-based (character user interface, or
CUI) terminal screens
– May use CASE tool called a screen scraper to
generate a quick GUI from a CUI
– Client does presentation and pres. logic layers
• Still is fundamentally centralized computing
INFO 503
Lecture #5
49
Distributed Data
• Distributed data (two-tier client/server) puts
stored data on the server, and business logic
and user interfaces on the clients
– A local or wide area network (LAN or WAN)
connects clients and servers
– Reduces network traffic compared to file server
architecture; easier to maintain data integrity
– This is classic 1980’s client/server design
INFO 503
Lecture #5
50
Distributed Data and Application
• Also called three-tiered or n-tiered
client/server, this distributes data and
application logic to separate servers
– Adds an application or transaction server
to monitor transactions & handle application
logic functions
– Client still handles presentation and pres. logic
– Is relatively new but increasingly common
INFO 503
Lecture #5
51
Network Computing
• Network computing distributes presentation
logic to web servers, while web browsers
handle only the presentation layer
– Otherwise looks the same as n-tier client/server
– Is the foundation for most e-commerce systems
• Maintaining security is a major challenge
• Emerging as foundation for widely
distributed computing and data structures
INFO 503
Lecture #5
52
Data Architecture
• Relational databases are the most common
tool used across distributed data architecture
• The database engine is what handles data
– Data may be distributed across servers
– One table may be partitioned vertically (fields)
or horizontally (records) across several servers
– Data may be replicated across servers, too
INFO 503
Lecture #5
53
Interface Architecture
• Many options exist for handling interfaces
• Batch input and output is used to handle a
large group of transactions at once
• On-line processing handles transactions
as needed
• Remote batch processing handles a batch
somewhere else; good for mobile users
INFO 503
Lecture #5
54
Interface Architecture
• Keyless data entry tries to eliminate high
volume input errors, using optical character
recognition (OCR) or bar codes
• Pen input is often used for simpler data
• Graphical user interfaces are the de facto
standard for most applications
• E-mail has grown into groupware, for
coordinating activities
INFO 503
Lecture #5
55
Interface Architecture
• Electronic data interchange (EDI) conducts
transactions among businesses
• Image and document interchange is like
EDI; but captures literal images (photos)
• Middleware helps apps communicate with
each other, such as ODBC database systems
• These options may be used company-wide,
or left for individual projects to select
INFO 503
Lecture #5
56
Process Architecture
• Software development environments
(SDE’s) are generally selected to match
the network architecture
– How a system will be deployed affects how
it is developed
• Centralized and distributed presentation
typically use COBOL, with a CICS
transaction monitor, and VSAM or DB2
for managing files and data
INFO 503
Lecture #5
57
Process Architecture
• Two-tier client/server is the most mature
option for selecting an SDE
– Tools like PowerBuilder, Delphi, Visual Studio
are available; SQL commands are understood
by all major database engines
– Testing, debugging, testing, writing, and help
authoring tools are also available
– Clean layering enforces separate presentation,
application, and data layers
INFO 503
Lecture #5
58
Process Architecture
• Multi-tier client/server typically must
support 1000+ users and 1+ TB databases
– Client and server must support cross-platform
environment - Windows, Unix, Mac
– Coding is often object-oriented; C++, C#,
Ada95, Smalltalk, etc.
– Tools include Forté, IBM VisualAge, etc.
INFO 503
Lecture #5
59
Process Architecture
• Network computing uses purely Internetbased tools
– HTML for page content and hyperlinks
– Computer Gateway Interface (CGI)
components, using Perl, Visual Basic’s
ActiveX, etc.
– Java and its cousins
– XML (= SGML lite) to enhance understanding
of document content
INFO 503
Lecture #5
60
Application Architecture Strategy
• Enterprise AA strategy defines corporate
standards for technology, tools, processes
• Tactical AA strategy defines standards
from scratch for each project, based on
their research and needs
• A key part of these choices is whether to
buy existing tools, or build custom ones
INFO 503
Lecture #5
61
Network Topology Overview
• There are four major topologies (structures)
for a physical computer network
–
–
–
–
Bus
Ring
Star
Hierarchical
• Each may use specific protocols (languages)
to communicate among the computers
INFO 503
Lecture #5
62
Network Topology - Bus
• A key function to achieve connectivity
among computers is definition of the
network topology
• The “bus” is the simplest topology - it
connects computers along a single line
• A peer-to-peer (serverless) network uses the
bus topology, with AppleTalk or Ethernet
INFO 503
Lecture #5
63
Ring Topology
• The ring topology connects computers in a
loop, and passes packets of data from one
computer to the next
• IBM’s Token Ring is the most
famous example
• Bad if a computer falls off the network –
hard to tell who dropped the packet
INFO 503
Lecture #5
64
Star Network
• Many clients may be connected to each
server across a star network
• The middle of each star is a server
• Servers are connected to each other
• Very common – think of using a server for
each department, and be able to control
which departments can see each other
INFO 503
Lecture #5
65
Hierarchical Network
• This is a set of nested star networks, looks
kind of like an organization chart
• Generally the servers get smaller the further
down the hierarchy
• Sometimes used in very large corporations,
where the biggest servers store companywide or division-wide data
INFO 503
Lecture #5
66
Network Protocols
• Networks allow computers to communicate
using standard languages (protocols)
– Most common are Ethernet and TCP/IP
– Others include Token Ring, IPX, SNA,
and AppleTalk
• Network operating systems
– Windows 2000 Server & 2003 Server, Unix,
Linux, NetWare, OS/2, Mac OS X Server
INFO 503
Lecture #5
67