Physical Level Systems Design: A Methodology for Inclusion in Our Systems Analysis and Design Textbooks Paul H. Rosenthal L. Jane Park College of Business.

Slides:



Advertisements
Similar presentations
Systems Analysis & IT Project Management Pepper. System Life Cycle BirthDeathDevelopmentProduction.
Advertisements

Copyright © 2015 Pearson Education, Inc. Systems Documentation Techniques Chapter
Systems Documentation Techniques
Configuration Management Managing Change. Points to Ponder Which is more important?  stability  progress Why is change potentially dangerous?
Using UML, Patterns, and Java Object-Oriented Software Engineering Royce’s Methodology Chapter 16, Royce’ Methodology.
T-FLEX DOCs PLM, Document and Workflow Management.
IS6112 Application Modelling and Design Introduction.
INFORMATION SYSTEMS PLANNING Module A. Stakeholder Requirements Specification Information Technology Staff Analysis Design and Implementation Requirements.
Distributed Systems and the WWW Extending the Capability of Massively Multiplayer Online Games by Introducing Distributed Systems as World Servers Jason.
Transaction Processing Systems: The Need for Systems Design Methodology Teaching Paul Rosenthal California State University, Los Angeles.
Requirements - Why What and How? Sriram Mohan. Outline Why ? What ? How ?
McGraw-Hill/Irwin Copyright © 2007 by The McGraw-Hill Companies, Inc. All rights reserved. Chapter 1 Introduction to Database Management.
Introduction to z/OS Basics © 2006 IBM Corporation Chapter 8: Designing and developing applications for z/OS.
Progress Report Nizar R. Mabroukeh
Information Systems Education: What’s missing? Paul H. Rosenthal Information Systems Department, California State University, Los Angeles.
IS 421 Information Systems Analysis James Nowotarski 4 November 2002.
Modeling the Processes and Logic
High-Level Assessment Month Year
 INPUT: Acxiom Corporation collects 300 million individual demographic records.  OUTPUT: Who is going to default on a loan.  Q: How do you process.
Chapter 1 Introduction to Database Management. McGraw-Hill/Irwin © 2004 The McGraw-Hill Companies, Inc. All rights reserved. Welcome! Database technology:
The chapter will address the following questions:
Introduction to the new mainframe © Copyright IBM Corp., All rights reserved. Chapter 7: Designing and developing applications for z/OS.
Lesson 1 Week01.
CIS 321—IS Analysis & Design Chapter 1: The World of the Modern Systems Analyst.
Implementation of HUBzero as a Knowledge Management System in a Large Organization HUBBUB Conference 2012 September 24 th, 2012 Gaurav Nanda, Jonathan.
Managing the development and purchase of information systems (Part 1)
Using Dataflow Diagrams – Part 2 Systems Analysis and Design, 7e Kendall & Kendall 7 © 2008 Pearson Prentice Hall.
Information Systems Analysis and Design
WEB-BASED DEAL LOG DATABASE PROJECT REVIEW Presented to SHEPHERD VENTURES By Sylvia Szubrycht.
Software Requirements Presented By Dr. Shazzad Hosain.
Introduction to Database Management. 1-2 Outline  Database characteristics  DBMS features  Architectures  Organizational roles.
Service Transition & Planning Service Validation & Testing
Chapter 10 Information Systems Analysis and Design
Chapter 6 SAS ® OLAP Cube Studio. Section 6.1 SAS OLAP Cube Studio Architecture.
OBJECT ORIENTED SYSTEM ANALYSIS AND DESIGN. COURSE OUTLINE The world of the Information Systems Analyst Approaches to System Development The Analyst as.
13-1 Application Architecture Application architecture – a specification of the technologies to be used to implement information systems. The blueprint.
Slide 1 Project Management Chapter 4. Slide 2 Objectives ■ Become familiar with estimation. ■ Be able to create a project workplan. ■ Become familiar.
An application architecture specifies the technologies to be used to implement one or more (and possibly all) information systems in terms of DATA, PROCESS,
Principles of Information Systems, Sixth Edition Organizing Data and Information Chapter 5.
1 Categories of data Operational and very short-term decision making data Current, short-term decision making, related to financial transactions, detailed.
5 - 1 Copyright © 2006, The McGraw-Hill Companies, Inc. All rights reserved.
1 Topics about Data Warehouses What is a data warehouse? How does a data warehouse differ from a transaction processing database? What are the characteristics.
REQUIREMENTS - WHY WHAT AND HOW? Steve Chenoweth & Chandan Rupakheti CSSE 371 Chapters Requirements Text. Question 6.
1 Categories of data Operational and very short-term decision making data Current, short-term decision making, related to financial transactions, detailed.
Computer Concepts 2014 Chapter 10 Information Systems Analysis and Design.
Systems Planning and Project Planning: Is Integration Needed? One of the weaknesses in our current SDLC methodologies is the isolation of system design.
Does IS Education Address Enterprise IT User Concerns? Bart Longenecker University of South Alabama Paul Rosenthal California State University, Los Angeles.
1 Categories of data Operational and very short-term decision making data Current, short-term decision making, related to financial transactions, detailed.
Oman College of Management and Technology Course – MM Topic 7 Production and Distribution of Multimedia Titles CS/MIS Department.
6 Systems Analysis and Design in a Changing World, Fourth Edition.
McGraw-Hill/Irwin Copyright © 2006 by The McGraw-Hill Companies, Inc. All rights reserved. Chapter 5 Modeling the Processes and Logic.
Public Management Information Systems System Analysis & Design Saturday, June 11, 2016 Hun Myoung Park, Ph.D. Public Management & Policy Analysis Program.
Final Review Systems Analysis and Design in a Changing World, 4th Edition 1 Final Review u Chapters 1-6, 8-10, 13, 14, 15 u Multiple choice, short answer,
Unit F451 Computer Fundamentals Components of a Computer System Software Data: Its representation, structure and management in information.
GDT Automated Scheduling and Operations with C2O.
Project Planning: Scope and the Work Breakdown Structure
Systems Documentation Techniques
System Design, Implementation and Review
Presentation on Software Requirements Submitted by
Software Specification Tools
Systems Analysis and Design
FORMAL SYSTEM DEVELOPMENT METHODOLOGIES
G063 - Data flow diagrams.
Tech Ed 2004 © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express.
.NET vs. J2EE Architecture
Keng Siau Department of Management University of Nebraska - Lincoln
Joint Application Development (JAD)
Project Manager Application
Week 10 Systems Development
Presentation transcript:

Physical Level Systems Design: A Methodology for Inclusion in Our Systems Analysis and Design Textbooks Paul H. Rosenthal L. Jane Park College of Business and Economics California State University, Los Angeles

Physical System Design: Completes the Planning/Justification Life-Cycle

The Physical Design Methodology A physical design is created from a DFD based logical design, by separating processes, data stores, and interfaces by time (daily vs. monthly, day vs. night...), place (client or server, centralized vs. distributed...), online vs. batch, manual vs. automated, etc.

Levels of Physical Design Charting Enterprise Application Level Business Process Level Program Level Using VISIO Symbols

Enterprise Application Level TPS Example

A Simplification from Turban

Business Process Level

Program Level

The Simplification from Langer

The Key Tool in Planning/Justification: Estimation It is possible to estimate Software Projects accurately. Such estimation is useful. Why? Once all stakeholders agree on estimation procedures, negotiations can involve inputs (features and resources) NOT outputs (time and dollars). Function Point measures are the most popular for Information Systems estimation. Illustration Follows

Function Points Methodology

Analyzing the Information Domain

We need to raise the Justification content level in our courses so that our graduates will be able to specify, estimate, design, and implement high quality and successful systems, and continue to reduce our industry's high project failure rate. Note: “Successful systems” are defined as those measured and confirmed useful by their end users in their operational environment SUMMARY STATEMENT