Introduction to information systems analysis systems design application architecture modeling
This presentation is the property of its rightful owner.
Sponsored Links
1 / 67

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


  • 91 Views
  • Uploaded on
  • Presentation posted in: General

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

Download Presentation

Introduction to Information Systems Analysis Systems Design Application Architecture & Modeling

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


Prototyping

Prototyping

  • 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


Prototyping1

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

Lecture #5


Prototyping2

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

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


  • Login