Introduction to information systems analysis systems design application architecture modeling
1 / 67

Introduction to Information Systems Analysis Systems Design Application Architecture & Modeling - PowerPoint PPT Presentation

  • Uploaded on

Introduction to Information Systems Analysis Systems Design Application Architecture & Modeling. INFO 503 Glenn Booker. System Design. System Design (a.k.a. physical design) includes the evaluation of alternative solutions, and specification of a detailed solution

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about ' Introduction to Information Systems Analysis Systems Design Application Architecture & Modeling' - parker

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Introduction to information systems analysis systems design application architecture modeling

Introduction to InformationSystems AnalysisSystems DesignApplication Architecture & Modeling

INFO 503

Glenn Booker

Lecture #5

System design
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

Lecture #5

Design strategies
Design Strategies

  • Modern structured design

  • Information engineering

  • Prototyping

  • Object-Oriented Design (OOD)

  • Joint Application Development (JAD)

  • Rapid Application Development (RAD)

Lecture #5

Modern structured design
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

Lecture #5

Modern structured design1
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

Lecture #5

Information engineering
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

Lecture #5


  • Developing prototypes:

    • 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


  • 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

Lecture #5


  • 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

Lecture #5

Object oriented design
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)

Lecture #5

Joint application development
Joint Application Development

  • JAD can be used for participative development of a design, in conjunction with other design techniques

Lecture #5

Rapid application development
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

Lecture #5

Fast design methodology
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 Designand Integration Phase, this is detailed design before construction of the system

Lecture #5

Decision analysis configuration phase
Decision Analysis (Configuration) Phase

  • The decision analysis phase identifies candidate configurations, and picks the best

  • Activities are:

    • 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

Identify candidate solutions
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

Lecture #5

Identify candidate solutions1
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

Lecture #5

Analyze candidate solutions
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)

Lecture #5

Compare candidate solutions
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!

Lecture #5

Update the project plan
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

Lecture #5

Recommend a system solution
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

Lecture #5

Procurement phase
Procurement Phase

p. 487 (326)

  • The procurement phase is to assess off-the-shelf 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

Lecture #5

Procurement phase1
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

Lecture #5

Research technical criteria and options
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

Lecture #5

Solicit proposals from vendors
Solicit Proposals from Vendors

  • Based on the technical criteria, prepare a request for quotation (RFQ) or arequest 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

Lecture #5

Validate vendor claims and performance
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

Lecture #5

Evaluate and rank vendor proposals
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)

Lecture #5

Award contract and debrief vendors
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

Lecture #5

Physical design integration phase
Physical Design & Integration Phase

  • This phase bridges the gulf between the user requirements and the builders’ input needs

    • 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

Design the application architecture
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)

Lecture #5

Design the system database
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)

Lecture #5

Design the system interface
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)

Lecture #5

Package design specifications
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

Lecture #5

Update project plan
Update Project Plan

Mary had a little lambWhose fleece was white as snowAnd everywhere that Mary wentShe 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!)

Lecture #5

Application architecture
Application Architecture

  • Return to general design focus, not detailed

  • Application architecture addresses general system design and technology issues:

    • 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

Modeling application architecture
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.)

Lecture #5

Modeling application architecture1
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:

    • 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

Modeling application architecture2
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

Lecture #5

Modeling application architecture3
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

Lecture #5

It architecture
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

Lecture #5

Five application layers
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

Lecture #5

It architecture1
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

Lecture #5

It architecture2
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

Lecture #5

It architecture3
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

Lecture #5

It architecture4
IT Architecture

  • Architecture options (see p. 511 (355)) are:

    • 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

Centralized computing
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

Lecture #5

File server architecture
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)

Lecture #5

Client server architecture
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

Lecture #5

Server types
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

Lecture #5

Distributed presentation
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

Lecture #5

Distributed data
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

Lecture #5

Distributed data and application
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

Lecture #5

Network computing
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

Lecture #5

Data architecture
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

Lecture #5

Interface architecture
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

Lecture #5

Interface architecture1
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

Lecture #5

Interface architecture2
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

Lecture #5

Process architecture
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

Lecture #5

Process architecture1
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

Lecture #5

Process architecture2
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.

Lecture #5

Process architecture3
Process Architecture

  • Network computing uses purely Internet-based 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

Lecture #5

Application architecture strategy
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

Lecture #5

Network topology overview
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

Lecture #5

Network topology bus
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

Lecture #5

Ring topology
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

Lecture #5

Star network
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

Lecture #5

Hierarchical network
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 company-wide or division-wide data

Lecture #5

Network protocols
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

Lecture #5