WS3 Project Planning Business Systems

Slides:



Advertisements
Similar presentations
© Copyright 2006 FPT Software 1 © FPT SOFTWARE – TRAINING MATERIAL – Internal use 04e-BM/NS/HDCV/FSOFT v2/3 How to work in Fsoft project Authors: KienNT.
Advertisements

Chapter 14 Intranets & Extranets. Awad –Electronic Commerce 1/e © 2002 Prentice Hall 2 OBJECTIVES Introduction Technical Infrastructure Planning an Intranet.
Analysis of Computer Algorithms
Chapter 1: The Database Environment
Chapter 26 Legacy Systems.
Chapter 7 System Models.
Requirements Engineering Process
Modern Systems Analyst and as a Project Manager
Technical System Options
1 9 Moving to Design Lecture Analysis Objectives to Design Objectives Figure 9-2.
Making the System Operational
Database Design Using the REA Data Model
Information Systems Analysis and Design
Week 2 The Object-Oriented Approach to Requirements
Chapter 11: Models of Computation
Service Level Agreement
Legacy Systems Older software systems that remain vital to an organisation.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software processes 2.
Lecture 5: Requirements Engineering
Introduction to Databases
Chapter 10: The Traditional Approach to Design
Systems Analysis and Design in a Changing World, Fifth Edition
James A. Senn’s Information Technology, 3rd Edition
© Prentice Hall CHAPTER 15 Managing the IS Function.
Database Systems: Design, Implementation, and Management Tenth Edition
Chapter 7 Structuring System Process Requirements
Information Systems Analysis and Design
Network Design and Implementation
1 History of Computers Module 1 Section 1 Source: nfo.lindows.com/examples/powerpoint_example2.ppt.
Communication Notation Part V Chapter 15, 16, 18 and 19.
Copyright 2002 Prentice-Hall, Inc. Chapter 1 The Systems Development Environment 1.1 Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer.
Data Flow Diagramming. Data Flow Diagrams Data Flow Diagrams are a means to represent data transformation processes within an information system.
Systems Development Life Cycle
Copyright 2004 Prentice-Hall, Inc. Essentials of Systems Analysis and Design Second Edition Joseph S. Valacich Joey F. George Jeffrey A. Hoffer Chapter.
Supplement 02CASE Tools1 Supplement 02 - Case Tools And Franchise Colleges By MANSHA NAWAZ.
Introduction to Systems Analysis and Design
Copyright 2001 Prentice-Hall, Inc. Essentials of Systems Analysis and Design Joseph S. Valacich Joey F. George Jeffrey A. Hoffer Chapter 1 The Systems.
staffs.ac.uk Process Model. staffs.ac.uk Contents Provide definitions Explain the components and representations Introduce a step.
Systems Analysis and Design: The Big Picture
Systems Analysis – Analyzing Requirements.  Analyzing requirement stage identifies user information needs and new systems requirements  IS dev team.
INFORMATION SYSTEM APPLICATIONS System Development Life Cycle.
Managing the development and purchase of information systems (Part 1)
Copyright 2002 Prentice-Hall, Inc. Chapter 1 The Systems Development Environment 1.1 Modern Systems Analysis and Design.
Data Flow Diagrams.
Copyright 2002 Prentice-Hall, Inc. Chapter 1 The Systems Development Environment 1.1 Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer.
System Development Process Prof. Sujata Rao. 2Overview Systems development life cycle (SDLC) – Provides overall framework for managing system development.
Chapter 14 Information System Development
Chapter 10 Information Systems Analysis and Design
Systems Analysis and Design
Computer Organization & Assembly Language © by DR. M. Amer.
Systems Development Life Cycle
Connecting with Computer Science2 Objectives Learn how software engineering is used to create applications Learn some of the different software engineering.
Software Requirements Specification (SRS)
Chapter 12 The Network Development Life Cycle
2 1 Database Systems: Design, Implementation, & Management, 7 th Edition, Rob & Coronel Data Models Why data models are important About the basic data-modeling.
1 Architectural Blueprints—The “4+1” View Model of Software Architecture (
SYSTEMS ANALYSIS AND DESIGN ITDB 2101 HAND OUT # 3 1.
Public Management Information Systems System Analysis & Design Saturday, June 11, 2016 Hun Myoung Park, Ph.D. Public Management & Policy Analysis Program.
 System Requirement Specification and System Planning.
Systems Development Life Cycle
Information Systems Development
Information Systems Development
Chapter 6 The Traditional Approach to Requirements.
Managing the development of information systems (Part 1)
Introduction to Systems Analysis and Design Stefano Moshi Memorial University College System Analysis & Design BIT
Members: Keshava Shiva Sanjeeve Kareena
Systems Development Life Cycle
UNIT No- III- Leverging Information System ( Investing strategy )
Presentation transcript:

WS3 Project Planning Business Systems CIS570 WS3 Project Planning Business Systems Joseph Lewis Aguirre

Project Planning - MGMT Manager’s Role in Project Planning Project Champion Project Planning

Project Planning - Plan Components of Business Project Plan Feasibility Study Business Requirements Definition Detailed Requirements Definition Solution Design Systems Development and Implementation

Project Planning- Scheduling Project Scheduling Constraints Phased Milestones Resources Forward/Backwards Scheduling

Project Planning- Cost Cost Estimation HW/SW In House/Outsource Training/Maintenance Cost Estimation Models

Project Planning- Alternatives Feasibility of technology alternatives Internet Intranet Extranet

CIS570 Project Management Joseph Lewis Aguirre

Sample Laws Moore’s law predicts the doubling of computing power every 18–24 months Gilder’s law predicts the doubling of communications power every six months Moore’s law predicts the doubling of computing power every 18–24 months due to the rapid evolution of microprocessor technology. [Gordon Moore, the co-founder of Intel, predicted in 1965.] Gilder’s law predicts the doubling of communications power every six months—a bandwidth explosion — due to advances in fiber-optic network technologies. [George Gilder, Into the Fibersphere, Forbes ASAP, Dec. 7, 1992, at 111] Both these effects are accompanied by huge reductions in costs. Let’s see how Moore’s law has operated in practice ….

Moore’s Laws 128KB 128MB 2000 8KB 1MB 8MB 1GB 1970 1980 1990 1M 16M bits: 1K 4K 16K 64K 256K 4M 64M 256M 1 chip memory size ( 2 MB to 32 MB) Transistor density doubles every 18 months 60% increase per year Chip density transistors/die Micro processor speeds Exponential growth: The past does not matter 10x here, 10x there … means REAL change PC costs decline faster than any other platform Volume and learning curves PCs are the building bricks of all future systems

Computer Components must evolve at the same time Amdahl’s law: one instruction per second requires one byte of memory and one bit per second of I/O Processor speed has evolved at 60% Storage evolves at 60% Wide Area Network speed evolves at 60% Local Area Network speed evolved 26-60% Grove’s Law: Plain Old Telephone Service (POTS) thwarts speed, evolving at 14%!

Economics based laws Demand: doubles as price declines by 20% Learning curves: 10-15% cost decline with 2X units Bill’s Law for the economics of PC software Nathan’s Laws of Software -- the virtuous circle Metcalfe’s Law of the “value of a network”

Metcalf’s Law of Network Utility How many connections can it make? 1 user: no utility 100,000 users: a few contacts 1 million users: many on Net 1 billion users: everyone on Net That is why the Internet is so “hot” Exponential benefit

Software Economics – Bills’ Laws Fixed_cost Price Marginal _cost = + Units Bill Joy’s law (Sun): don’t write software for <100,000 platforms @$10 million engineering expense, $1,000 price Bill Gate’s law: don’t write software for <1,000,000 platforms @$10M engineering expense, $100 price Examples: UNIX versus Windows NT: $3,500 versus $500 Oracle versus SQL-Server: $100,000 versus $6,000

The Virtuous Economic Cycle driving the Compute Element Competition Volume Standards Utility/value Innovation

Nathan’s Laws of Software 1. Software is a gas. It expands to fill the container it is in 2. Software grows until it becomes limited by Moore’s Law 3. Software growth makes Moore’s Law possible 4. Software is only limited by human ambition and expectation …GB: and our ability to cyberize I.e. encode

Everything Cyberizable in Cyberspace Body Continent Region/ Intranet Cars… phys. nets Home… buildings Campus World Fractal Cyberspace: a network of … networks of … platforms 26

Enablers “The Computer” Mainframe tube, core, drum, tape, batch O/S direct > batch Mini & Timesharing SSI-MSI, disk, timeshare O/S terminals via commands POTS PC/WS micro, floppy, disk, bit-map display, mouse, dist’d O/S WIMP LAN Web browser, telecomputer, tv computer PC, scalable servers, Web, HTML Internet Network Interface Platform

Future Computer Classes

Platform Economics Computer type Traditional computers: custom or semi-custom, high-tech and high-touch New computers: high-tech and no-touch 100000 10000 Price (K$) 1000 Volume (K) 100 Application price 10 1 0.1 0.01 Mainframe WS Browser Computer type

Virtuous Cycle Driving Bandwidth User demand Application innovation Internet (IP) ubiquity Capac. (svc & response) Excess capac. -->>BW

Software Economics Microsoft: $9 billion An engineer costs about $150K/year R&D gets [5%…15%] of budget Need [$3 million… $1 million] revenue per engineer Profit 24% R&D 16% Tax 13% SG&A 34% Product and Service 13% Intel: $16 billion IBM: $72 billion Oracle: $3 billion Profit 6% Profit 15% R&D 8% R&D 9% Profit R&D 8% Tax 5% 22% Tax 7% SG&A 11% SG&A 22% Tax SG&A 12% P&S 47% P&S 59% P&S 26% 43%

BIG THREE MODELS Context Model Event Model SCOPE Information Model

Rational Rose Model End user Programmers Analysts/Testers - Functionality - Vocabulary Programmers - Software management Design view Component view Use case view Analysts/Testers - Behavior Process view Deployment view System integrators - Performance - Scalability - Throughput System engineering - System topology - Delivery and installation - Communication 17

USE CASE DIAGRAMS Documents user-system interactions required to perform tasks

USE CASE DIAGRAMS

Business Process Modeling For each icon ask:mission, tasks, problems, decisions, metrics, who else needs to be informed? Sales Order Processing Systems design specifies how the system will accomplish the objectives of meeting the information needs of users as described by the systems analysis. Design activities produce system specifications satisfying the functional requirements identified earlier. Specifications are then used to develop or acquire the necessary components and skills to implement the system. The systems design concept focuses on three major products or deliverables: User Interface Design. This activity focuses on the interaction between end users and computer systems. In the E-Business, designers concentrate on designing attractive and efficient forms for user input and output on intranet pages. Prototyping is often used at this stage to involve users in developing acceptable interfaces. Data Design. This activity focuses on the design of the structure of databases and files to be used by a proposed information system. Data design frequently produces a data dictionary, which catalogs detailed descriptions of the attributes of entities (objects, people, places, events) about which the IS needs to maintain information. The data dictionary also specifies the relationship entities have to each other, the specific data elements for each entity, and the integrity rules governing how each data element is specified and used in the IS. Process Design. This activity focuses on the design of software resources -- the programs and procedures needed by the proposed IS. System Specifications. Completion of the previous areas of system design culminate in a clear statement of system specifications for the User Interface, Database, Software, Hardware and Facilities, and Personnel components of the IS.

Context Model

What is Context • Context influences how we perceive information. • Context enables us to manage the vast amount of information that surrounds us. • Context guides us through the information surrounding us. • Context allows to discriminate what is important and what is not. • Context helps us to adapt to our surroundings.

Not much meaning without context? Context Model I'm going to have to I'm going to really have to, yes, manipulate on I'll leave B and C on full tilt now I'm going to have to manipulate one of these if I want to cut down if I'm going to go over it 4 minutes and I've used 6 I've got A oxidising Not much meaning without context?

Context Model Possible relationship between context size and cognitive demand Cognitive Demand High Total Cognitive Demand Between Context Low Within Context Small Large Context Size

TRUISMS It is not the plan that matters, It’s the planning. -General Dwight D. Eisenhower Graphical Diagrams do not constitute a specification….nothing replaces clear, concise text. - David A. Ruble At a recent study, I commented at one point in our deliberations that we had spent more time on wordsmithing than we had on considering the substance of our report. -- Robert W. Lucky, VP for Applied Research at Telecordia. NJ It seems to me language by its very nature is imprecise. I think of each word as inhabiting a fuzzy ball of uncertain semantic meaning…. – Robert W. Lucky

Context Model External Agent Stimulus Response System Processing Control Output Input System External Agent Stimulus Response The systems approach views a business process as a system that has 5 components: input, process, output, feedback and control. The systems approach to problem solving uses the systems orientation to conceptualize the nature of the problem. Under the systems orientation, all elements of a problem interact with one another. Consequently, the systems approach considers each "step" to influence and provide feedback on every other step: Define the Problem. A problem is a basic condition that is causing an undesirable result. An opportunity is a basic condition that presents the potential for desirable results. A key task at this stage is to separate symptoms -- signs that a problem exists -- from the actual problems themselves. Develop Alternative Solutions. It is almost always true that every problem or opportunity has more than one effective course of action. As a problem solver, you must resist the tendency to move to the most immediate solution that comes to mind. It is good management practice to generate several alternatives and choose among them on the basis of clearly defined evaluative criteria. Select the Solution. On the basis of evaluative criteria, it is possible to compare alternatives to each other. Selection is important because there must be firm commitment to the alternative before committing organizational resources to solving the problem. Design the Solution. The selected solution to an IS problem next requires designing how the solution will be created. Here it is a good idea to meet with business end users and technical staff to develop design specifications and an implementation plan. Implement the Solution. When ready, the solution must be implemented. It is a good idea to monitor implementation carefully so that an assessment of the solution, design, and the logistics of bringing it into action can all be evaluated objectively.

Data Flow Modeling Understand the flows of data around the system Define processes that transform or manipulate data Identify the sources and recipients of data outside the system Show where data is held in the system Aid communication between user and analyst Form the basis of function definition and event identification

Data Flow Modeling Typically three versions of the DFM are produced: Current physical DFM Logical DFM Required system DFM

Data Flow Modeling The data flow model consists of: Data flow diagrams (DFD) Elementary process descriptions (EPD) External entity descriptions I/O descriptions

DATA FLOW DIAGRAMS Given well specified processes and the information required to support those process, Data Flow Diagrams (DFD) are use to represent the data acquisition, transformation, storage and delivery process. Five areas of knowledge are important to end users in order to understand information systems: Foundation Concepts. End users must be familiar with with the basic components and types of information systems there are. But they also need to be familiar with general systems theory and theories of information processing (machine and human). These topics are covered in Chapters 1 -2 and others. Technology. End users should understand technology, more precisely, the information technology of hardware, software, networks, database management, and other information processing technologies. All these elements interaction in a dynamic process of very rapid change, development, and new ways of doing business (See Chapters 4-7). Applications. How information systems are applied to business problems is more complex than it might seem. The informed end users seeks to learn both about how to use information systems to solve existing problems and to begin using IS as a new way of defining problems and meeting business opportunities. End users should gain a basic understanding of the major uses of information systems for the operations, management, and competitive advantage of an enterprise, including electronic commerce and collaboration using the Internet, intranets, and extranets. (Chapters 8-12). Development. End users of IS need to know the fundamental concepts of problem-solving and development methodologies. Here you should become familiar with methodologies such as the systems approach, the systems development life cycle, and prototyping (Chapter 3). Management. How managers make use of IS resources is a key concern for end users. More than ever, a knowledge of management methods is required by each end users, as IT demands that end users make more independent decisions that support the company's overall objectives. (Chapters 13-15, and throughout the text). External Entities: People or systems Data Flows: Data content acquired from an external entity. Processes: Transform data according to business rules – strictly computer implemented processes Business rules and processing logic must be documented for each process. 9 9 3 3 3

Context Diagram A Representation of the Process Model

Data source/sink, external entity DFD – CONTEXT DIAGRAM Data source/sink, external entity Data/Process – strong action verb, followed by object Data Store

DFD Notation Law of transformation – a process transforms the data in some way Law of conservation – a process’ output must be derivable from its input, and should be given enough information to do its job Process: Strong action verb followed by object to which action applies - VO External agent – named using noun

CONTEXT DIAGRAM - PAYROLL Timecards Process Payroll. Pay Checks Employee Payroll Reports W2 Forms Tax Tables and Parameters Employee Fixed Data Payroll Manager

Outputs expressed in computer programming language Data Flow Diagram Outputs expressed in computer programming language Order Accounts Customer Process Order Invoice Invoice Process Entity Data Flow

Process Modeling A Process used to calculate FICA withholding taxes processing logic:   IF YtdGrossPay + CurrentGrossPay <= MaxFICAWages THEN ficaTax = CurrentGrossPay * FICATaxRate ELSE IF YtdGrossPay <= MaxFICAWages ficaTax = (MaxFICAWages - YtdGrossPay) * FICATaxRate ficaTax = 0 END IF Employee Payroll Manager Process Payroll.* Timecards Pay Checks W2 Forms Payroll Reports Tax Tables and Parameters Employee Fixed Data

DATA DICTIONARY Catalog describing the information and data used in the system Need entries for Processes (name, number, performed by, trigguer, volume, logic) Data Flows (name, description, frequency, structure) Data Stores (name, description, key elements, sequence, media, volume, organization, structure)

DATA DICTIONARY – DATA STORE Data Dictionary Sample Entry: Data Store File or Database Name: Accounting Aliases: Project Accounting Brief Description : Used to track projects and staffing levels Composition: Project Nuber + Project Description + Staff Count + Employee Name + Release Date Organization : Sequential by Project Number NOTES :

Event Model

Event Model Benefits Compared to hierarchical process model used to document requirements for monolithic process-driven programs, event model is more flexible

Event Model Effect Event Stimulus Response Environment System Control Stimulus Processing Response System The systems approach views a business process as a system that has 5 components: input, process, output, feedback and control. The systems approach to problem solving uses the systems orientation to conceptualize the nature of the problem. Under the systems orientation, all elements of a problem interact with one another. Consequently, the systems approach considers each "step" to influence and provide feedback on every other step: Define the Problem. A problem is a basic condition that is causing an undesirable result. An opportunity is a basic condition that presents the potential for desirable results. A key task at this stage is to separate symptoms -- signs that a problem exists -- from the actual problems themselves. Develop Alternative Solutions. It is almost always true that every problem or opportunity has more than one effective course of action. As a problem solver, you must resist the tendency to move to the most immediate solution that comes to mind. It is good management practice to generate several alternatives and choose among them on the basis of clearly defined evaluative criteria. Select the Solution. On the basis of evaluative criteria, it is possible to compare alternatives to each other. Selection is important because there must be firm commitment to the alternative before committing organizational resources to solving the problem. Design the Solution. The selected solution to an IS problem next requires designing how the solution will be created. Here it is a good idea to meet with business end users and technical staff to develop design specifications and an implementation plan. Implement the Solution. When ready, the solution must be implemented. It is a good idea to monitor implementation carefully so that an assessment of the solution, design, and the logistics of bringing it into action can all be evaluated objectively. Components, Relationships, Boundaries, Interfaces, Constraints

Event Model Deliverables Event List Event Dictionary Event Matrices

Event Lists S-V-O Customer returns merchandise Customer requests refund Customer places order Engineering requests bug list

EVENT DICTIONARY – FICA Event ID: 099 Alias: None Event Name: Calculate FICA Withholding Taxes Description : Simple tax withholding calculation using FICA Tax Rates Stimulus: Employee ID, Pay Period, Current gross pay and Year to Date Gross Pay

EVENT DICTIONARY - FICA (cont) Activity : Create an instance of FICA Withholding using employee ID, and Pay period. IF YtdGrossPay + CurrentGrossPay <= MaxFICAWages THEN ficaTax = CurrentGrossPay * FICATaxRate ELSE IF YtdGrossPay <= MaxFICAWages THEN ficaTax = (MaxFICAWages - YtdGrossPay) * FICATaxRate ELSE ficaTax = 0 END IF Statistics?

EVENT DICTIONARY- FICA (cont) Response : Withholding tax Effect : Can be printed and given to employee

EVENT DICTIONARY Event ID: 099 Alias: None Event Name: Warehouse ships customer order Description : When warehouse ships product, the trucking company is identified and quantity shipped for each item is updated on the customer order. If the total quantity shipped equals total quantity ordered, then the order item is closed out. If all items of the order have been filled, then the order is closed out. A BOL is produced by the system to accompany the shipment Stimulus: Employee ID, Pay Period

Event Model – Event List Customer Places Order Customer Cancels Order Warehouse ships order Accounting Invoices Order Customer Pays Invoice

Event Entity Matrix Order Item Plant Order Customer Order Customer Places Order Credit Approves Order Warehouse ships order Accounting Invoices Order Marketing Sends Literature CRU C C NA U UR R NA R R RU R R R R R NA R R R

Cross Check Cross Check Event Model with Information Model for missing entities, attributes, relationships If you have it, use it, else why have it Exceptions, such as non-events?

Event Organization – Event Chain Sort by Time – event chain Customer Places order Sales manager approves Production schedules order Factory produces order Factory ships order Time to issue statement Customer pays balance Syntax, exception management?

Event Organization – Event Subject Sort By Subject: Factory Events Customer Events Factory schedules order Factory produces order Factory ships order Factory closes shop Customer places order Customer pays deposit on order Customer cancels order Customer picks up order Customer does not pick up order Customer pays balanced due Customer does not pay balance Syntax, exception management?

Event Organization – Event Object Sort by Object: Price List Events Order Events Marketing established PL Sales manager requests PL Sales manager resquests sales report Customer places order Sales Manager approves order Customer cancels order Customer picks up order Customer does not pick up order Production schedules order Warehouse fills order Syntax, exception management?

Event Hierarchy Characteristics Characteristics Most appropriate for planning phase Next level of resolution Business Requirements sans U/I Conceptual Business Description of HCI as a function of user, technology, etc. Dialogue Actual navigsation structure Design

Event Hierarchy Conceptual Business Dialogue Design Customer Places order Conceptual Customer places preliminary order Sales Manager confirms order Production schedules order for shipment.. Business Five areas of knowledge are important to end users in order to understand information systems: Foundation Concepts. End users must be familiar with with the basic components and types of information systems there are. But they also need to be familiar with general systems theory and theories of information processing (machine and human). These topics are covered in Chapters 1 -2 and others. Technology. End users should understand technology, more precisely, the information technology of hardware, software, networks, database management, and other information processing technologies. All these elements interaction in a dynamic process of very rapid change, development, and new ways of doing business (See Chapters 4-7). Applications. How information systems are applied to business problems is more complex than it might seem. The informed end users seeks to learn both about how to use information systems to solve existing problems and to begin using IS as a new way of defining problems and meeting business opportunities. End users should gain a basic understanding of the major uses of information systems for the operations, management, and competitive advantage of an enterprise, including electronic commerce and collaboration using the Internet, intranets, and extranets. (Chapters 8-12). Development. End users of IS need to know the fundamental concepts of problem-solving and development methodologies. Here you should become familiar with methodologies such as the systems approach, the systems development life cycle, and prototyping (Chapter 3). Management. How managers make use of IS resources is a key concern for end users. More than ever, a knowledge of management methods is required by each end users, as IT demands that end users make more independent decisions that support the company's overall objectives. (Chapters 13-15, and throughout the text). Sales rep enters order header Sales rep enters request ship date Sales Mgr requests sales report Sales Mgr confirms order Production control agent requests order schedule Dialogue Sales rep clicks new order… Sales rep clicks requested ship date… Sales Mgr clicks find, enter order, click save…. Sales Mgr clicks find unconfirmed orders… Agent clicks find Design 9 9 3 3 3

Information Model

Information Model Static Map of data required to carry out policy of each event

Overview Entity: Definition (Reminder) The Importance of Keys The Entity Hierarchy Types of Keys: A Simple Key, A Compound Key, A Hierarchic (or Composite) Key, A Foreign Key, Navigation: Relationships and Keys Exercise

Entities person, place, object, event, or concept entity type (entity class) entity instance

Attributes property or characteristic of an entity candidate key--unique identifier primary key--unique ID selected multivalued attributes--have many values per instance hobbies, dependents, skills, languages

Relationships association between instances of one or more entities degree of relationship unary binary ternary--simultaneous relationship among 3 entities

Keys Candidate: Attribute that uniquely identifies each instance of an entity type Primary: Candidate key selected as identifier for entity type

Process Model

IS Models In general there are two types of models for the information systems environment—data models and process models.

Process Model Typically consists of the following (in whole or in part): Functional decomposition Context-level zero diagram Data flow diagram Structure chart State transition diagram HIPO chart Pseudocode

Process Model Because the process model is requirements-based, it is not suitable for the data warehouse.   The process model assumes that a set of known processing requirements exists, before the details of the design are established. But those assumptions do not hold for the data warehouse. Many development tools, such as CASE tools, have the same orientation and as such are not applicable to the data warehouse environment.

HIPO CHARTS Hierarchy input process output chart consist of 2 parts A chart showing the hierarchy of processes similar to a structure chart For each process in part, create a diagram which details the name of the process, inputs, what the inputs are used for, the outputs SYSTEM: Customer Accounts PROCESS NAME: Validate Customer INPUT: Customer ID PROCESS: Read customer record to see if customer number is valid OUTPUT: True or False Condition

Pseudocode Begin If While Repeat until Casewhere Then Else otherwise Detailed textual description of an algorithm using keywords. Begin If While Repeat until Casewhere Then Else otherwise end endif endwhile endrepeat endcase

Pseudocode while not at end of list compare adjacent elements if second is greater than first switch them get next two elements if elements were switched repeat for entire list

Data Model The data model is applicable to both the existing systems environment and the data warehouse environment.

Data Stability Analysis Parts Table Sometimes Changes Frequently Changes Seldom Changes Part Id Description Substitute QOH Order Unit Safety Stock Primary supplier Expediter Shipping manifest Lead time Accetable reject rate Last order date Last order amount Las delivery to Order amount Part-id Description Order unit Lead time Acceptable reject rate Shipping manifest Part-id Primary substitute Safety stock Primary supplier Expediter Part-id QOH Last order date Last order amount Last delivery to Order amount

Database Design Logical Design Information Requirements Logical Structure Design Data Model and Implementation Constraints Physical Design Physical Storage Class Alternatives Physical Tuning

Program Design Data Independence Program design to be independent from the logical data structure Build into the program a monitoring mechanism that will collect statistics on how the logical data structure is being utilized by the application

Entity Hierarchy MASTER DETAIL DETAIL DETAIL (MASTER) DETAIL DETAIL DETAIL DETAIL All relationships are based absolutely on the hierarchical concept of MASTER(PARENT) &DETAIL (CHILD)

ER Diagram Customer Order Employee Order Item Product Customer Rep Is represented by Customer Rep Customer Represents Was Placed By Placed Was taken by Order Product Price Employee Took Was ordered on Contains Request delivery of Retails for Order Item Product Is Price for Was ordered on

ER Diagram Notation Has been owned Has been owned Owned Owned

Context Model Furniture Mfg. from McFadden & Hoffer: Modern Database Management: 4th Edition, Benjamin/Cummings, 1994

ER Model – Furniture Mfg. Bills Customer Places Fulfills Order Invoice Requests Ships Product Uses Builds Raw Material Work Order Vendor Supplies

Information System Models In general there are two types of models for the information systems environment—data models and process models.

Information Requirements Process-oriented information Identifies which data are used by each process and how frequently the process is performed Data Models Addresses the organization’s conceptual view of the database: entities, attributes, and relationships

in the Technology Environment Project Management in the Technology Environment Joseph Lewis Aguirre

PROJECT MANAGEMENT

PROJECT SCOPE MANAGEMENT Planning Models

PROJECT SCOPE MANAGEMENT 1) Initiation 2) Scope planning 3) Definition 4) Verification 5) Change control

PROJECT SCOPE MANAGEMENT SELECTION METHODS 1) Net Present Value Return On Investment Payback Analysis

Technology Evaluation Factors Hardware Performance Cost Reliability Compatibility Technology Connectivity Scalability Support Software Software Quality Flexibility Security Connectivity Language Documentation Hardware Efficiency In today’s E-Business environment, acquisition of hardware, software, and IS services is an important part of E-application development. How should companies make such acquisition choices? What process should they use for selecting vendors? Larger businesses may require suppliers to present bids and proposals based on system specifications developed during the design phase. Many E-Businesses formalize these requirements into a document called an RFP (request for proposal). The selection process may sometimes involve a live test demo of software or hardware functionality, or a benchmark test, which is used to evaluate system performance through simulation of typical processing tasks. In each case hardware and software evaluation factors are used to judge the suitability of the component. Teaching tip: Consider discussing the individual factors shown on the slide. When acquiring IS services, other evaluation factors need to be considered. These include: Past Performance. Referrals from past customers is essential. Business Position. Is the vendor financially strong, with good industry prospects? Service and Capabilities. What kind of services can they offer? What kind of equipment do they have available? Accessibility. Does the vendor provide local or regional support? Maintenance and Guarantees. Will they maintain their product? Are there warranties?

WHO ARE THESE PEOPLE?

PM EXPERTISE

WHY DO PMs FAIL?

SUCCESSFUL PMs

IT PROJECT FAILURE RATE

Project Management Core Skills Scope Management Time Management Cost Management Quality Management Human Resources Communications Risk Management Procurement CORE SKILLS PROCESS Initiate Plan Execute Control Close Five areas of knowledge are important to end users in order to understand information systems: Foundation Concepts. End users must be familiar with with the basic components and types of information systems there are. But they also need to be familiar with general systems theory and theories of information processing (machine and human). These topics are covered in Chapters 1 -2 and others. Technology. End users should understand technology, more precisely, the information technology of hardware, software, networks, database management, and other information processing technologies. All these elements interaction in a dynamic process of very rapid change, development, and new ways of doing business (See Chapters 4-7). Applications. How information systems are applied to business problems is more complex than it might seem. The informed end users seeks to learn both about how to use information systems to solve existing problems and to begin using IS as a new way of defining problems and meeting business opportunities. End users should gain a basic understanding of the major uses of information systems for the operations, management, and competitive advantage of an enterprise, including electronic commerce and collaboration using the Internet, intranets, and extranets. (Chapters 8-12). Development. End users of IS need to know the fundamental concepts of problem-solving and development methodologies. Here you should become familiar with methodologies such as the systems approach, the systems development life cycle, and prototyping (Chapter 3). Management. How managers make use of IS resources is a key concern for end users. More than ever, a knowledge of management methods is required by each end users, as IT demands that end users make more independent decisions that support the company's overall objectives. (Chapters 13-15, and throughout the text). Leadership? Creativity? 9 9 3 3 3

PROJECT MANAGEMENT INTEGRATION 1) SCOPE 2) TIME COST QUALITY 5) HR 6) COMM 7) RISK 8) PROCURE

3C - SCOPE, TIME, COST Cost Performance SCOPE Performance Cost SCOPE Cost=f(P,T,S) SCOPE Time Cost Performance Cost SCOPE Time

Define Change Strategy Deliver Business Benefits Change Management Define Change Strategy Develop Leadership Build Commitment Deliver Business Benefits Create Change Vision Manage Performance Develop Culture Design Organization Set up Set Up Analysis Definition Transition

PROJECT SCOPE MANAGEMENT NET PRESENT VALUE (NPV) ->today's value of a series of future payments & income

PROJECT SCOPE MANAGEMENT PAYBACK ANALYSIS

WEIGHTED SCORING MODEL

Cascading Scorecards Business Units Support Units Team/ Individual Vision Mission Strategy Quickly Developing a Balanced Scorecard (Arcplan Info. Services, Germany)

Linking Metrics Objective Measure Target Initiatives Revenue mix Performance expectation Key action programs required to achieve objectives How success will be measured and tracked What strategy must be achieved and what is critical to its success Objective Measure Target Initiatives Revenue mix Customer retention % Revenue from new products Skill coverage 10% Product A 40% Product B 50% Product C 95% 1999 -- 15% 2000 -- 50% 2001 -- 60% 90% Sales Promotions New Channel Marketing Frequent Buyers’ Club R & D Program Customer Mailing Custom Training Knowledge Library Broaden revenue mix Increase customer satisfaction Develop new products Develop strategic skills Financial Customer Internal Learning & Growth

RESPONSIBILITY ASSIGNMENT MATRIX (RAM RAM integrates the Organization Breakdown Structure (OBS) with the Contract Work Breakdown Structure (CWBS)

Critical Path – shortest path in which the project can be completed TIME MANAGEMENT - CPM Critical Path – shortest path in which the project can be completed 4 Day Activity 8 Activity 2 Activity 5 6 Day 1 Day 5 Day Activity 6 3 Day Activity 1 Activity 3 4 Day 2 Day 2 Day 3 Day Activity 4 Activity 7 6 Day 16 Days

COST ANALSYS 02/10/99 2

COST ANALYSIS- EVA 02/10/99 2

COST ANALYSIS- EVA 02/10/99 2

COST ANALYSIS- RESOURCE LOADING 02/10/99 2

COST ANALYSIS- EAC 02/10/99 2

EVA - INTRODUCTION 02/10/99 EVA - a way to measure a project’s progress, forecast its completion date and final cost, and provide schedule and budget variances along the way. Based on just 3 sets of data, it can provide consistent, numerical indicators with which you can evaluate and compare projects. 2

FUNDAMENTAL METRICS Budgeted Cost of Work Performed. 02/10/99 Budgeted Cost of Work Performed. Budgeted Cost of Work Scheduled. Actual Cost of Work Performed. 3

DERIVED METRICS Schedule Variance (SV) 02/10/99 Schedule Variance (SV) Schedule Performance Index (SPI) Cost Variance (CV) Cost Performance Index (CPI) 7

MORE ACRONYMS BAC - Budget At Completion 02/10/99 BAC - Budget At Completion - Total Original Budgeted Cost Same as BCWS at completion EAC - Estimate At Completion Cumulative Actuals + Estimate-To-Complete VAC - Variance At Completion Forecast of final cost variance 8

DOING THE MATH SV = BCWP - BCWS SPI = BCWP / BCWS CV = BCWP - ACWP 02/10/99 SV = BCWP - BCWS Negative means Behind Schedule SPI = BCWP / BCWS Less than 1.00 means Behind Schedule CV = BCWP - ACWP Negative means Over Budget CPI = BCWP / ACWP Less than 1.00 means Over Budget EAC = BAC / CPI 9

IF LEMONS-> LEMONADE 02/10/99 Make 1,000 cups over 50 days Steady rate of 20 cups per day Budgeted cost per cup is $0.50 Total project budget is $500 10

STATUS EOD 10 At end of day 10: 150 cups have been made 02/10/99 At end of day 10: 150 cups have been made Total actual cost is $90 (ACWP) 11

PROJECT STATUS BCWS = $100 BCWP = $75 (Earned Value) 02/10/99 BCWS = $100 10 days x 20 cups per day x .50/cup budget BCWP = $75 (Earned Value) 150 cups x .50/cup budget SV = BCWP - BCWS = -$25 SPI = BCWP / BCWS = 0.75 CV = BCWP - ACWP = $75 - $90 = -$15 CPI = BCWP / ACWP = 0.833 12

PROJECT FORECAST 02/10/99 Estimate At Completion = Cumulative Actuals + Estimate-To-Complete EAC = BAC / CPI = $500 / 0.833 = $600 Variance At Completion = Forecast of final cost variance VAC = BAC - EAC = $500 - $600 = $100 (unfavorable) Schedule at Completion = 50 / SPI = 50 / 0.75 = 66.67 days 13

TMGT 510 TIME MANAGEMENT

PROJECT TIME MANAGEMENT Project schedules 1) GANTT Precedence Diagrams PERT Charts

Critical Path – shortest path in which the project can be completed TIME MANAGEMENT - CPM Critical Path – shortest path in which the project can be completed 4 Day Activity 8 Activity 2 Activity 5 6 Day 1 Day 5 Day Activity 6 3 Day Activity 1 Activity 3 4 Day 2 Day 2 Day 3 Day Activity 4 Activity 7 6 Day 16 Days

Average Time = (Best Case + (4 x Expected Case) + Worst Case) / 6 TIME MANAGEMENT - PERT PROGRAM EVALUATION & REVIEW (problems eventually resolve themselves) - A statistical technique applied to a network schedule. Activity 1 Activity 3 Activity 4 Activity 2 Activity 5 Activity 7 Activity 6 Activity 8 1 Day 3 Day 2 Day 4 Day 6 Day 5 Day Average Time = (Best Case + (4 x Expected Case) + Worst Case) / 6

TMGT 510 Work Shop 2 COST CONTROL Joseph Lewis Aguirre

SCOPE & TIME MANAGEMENT Cost Performance SCOPE TIME Cost=f(P,T,S)

WHERE ARE WE GOING? "Cheshire-Puss," she began, rather timidly, "Would you tell me, please, which way I ought to go from here?" "That depends a great deal on where you want to get to," said the cat. "I don't much care where -," said Alice. "Then it doesn't matter which way you go," said the cat. --Lewis Carroll Alice in Wonderland -

PROJECT ROAD MAP PAST PRESENT FUTURE Are we on schedule? Are we on cost? What are the significant variances? Why do we have variances? Who is responsible? What is the trend to date? When will we finish? What will it cost at the end? How can we control the trend? Analyze past performance………….…to help control the future

PROJECT COST CONTROL PROJECT COST CONTROL 03/04/2001 11/28/2001

COST CONTROL ROM RAM CPU

COST CONTROL Tangible Cost/Benefit Intangible Cost/Benefit Direct Costs Indirect Cost Sunk Cost Learning Curve Theory Reserves

PROJECT COST MANAGEMENT Cost avoidance window of opportunity 15% TIME

PROJECT COST MANAGEMENT

Cost estimate ROM Budgetary Definitive PROJECT COST MANAGEMENT Cost estimate ROM Budgetary Definitive Top/Down Parametric Analogous http://www.jsc.nasa.gov/bu2/COCOMO.html http://sunset.usc.edu/research/COCOMOII/index.html

PROJECT COST CONTROL

PROJECT COST MANAGEMENT WBS SCHEDULE COST ESTIMATES BUDGET SW Development Code Test Document Code: $10X Test: $1x Document: $0.5x $xxx.xxx.xxx

PROJECT COST CONTROL Good News? Planned cost COST Cost to Date TIME 02/10/99 Planned cost Cost to Date TIME COST Good News? 2

PROJECT COST CONTROL Apples and Oranges TASK STATUS Conceptual Design Program Specification Coding Documentation User Manual Production Debugging STATUS Complete In Process Not Yet Started 50% Complete?

PROJECT COST CONTROL TASK STATUS Conceptual Design Program Specification Coding Documentation User Manual Production Debugging STATUS Complete In Process Not Yet Started 50% Complete?

PROJECT COST CONTROL TASK BUDGET BUDGET Conceptual Design Program Specification Coding Documentation User Manual Production Debugging BUDGET 200 hours 300 hours 600 hours 100 hours 400 hours 500 hours BUDGET 200 earned 300 earned 150 earned 10 earned NYS TOTAL 2,100 hours 660 earned 31% Complete: 660/2100

PROJECT COST CONTROL EVA = f(% Complete) Uniform Unit of Measure CONSTRUCTION Concrete (cubic yards) Forms (sq ft) Pipe (ft) Rebar (tons) Conduit (ft) MOVIE INDUSTRY Screenplay writing Set Production Filming Editing Marketing

PROJECT COST CONTROL Physical Work: Task: Create Design drawing: Task: Pour 1000 cubic yards of concrete Progress: 300 done to date % complete  30% Task: Create Design drawing: 10% when preliminary study is complete 20% When draft is complete 40% First draft printed 50% First draft review 60% Second draft is complete 75% Customer review 90% Final draft is complete 100% Released for construction 50-50% Rule: 50% after its start date, 100% Finish

PROJECT COST CONTROL EAC (Estimate at Completion) BCWS BAC (Budget at Completion) FCST: Forecast of Remaining Work To Date Schedule Variance To Date Cost Variance ACWP EVA (BCWP) Data Date TIME BCWS: Budgeted Cost of Work Scheduled ACWP: Actual Cost of Work Performed EVA (BCWP): Budgeted Cost of Work Performed

PROJECT COST CONTROL EARNED VALUE METHODOLOGY Earned Value Analysis (EVA) Physical Progress (consistent) Uniform Unit of Measure EVA = f(% Complete)

TMGT 510 QUALITY MANAGEMENT

PROJECT QUALITY MANAGEMENT QUALITY CONTROL QUALITY ASSURANCE

PROJECT QUALITY MANAGEMENT Sigma Defective Units per Billion 2,700,000 6 2

PROJECT QUALITY MANAGEMENT Pareto Diagram

FIELD PERFORMANCE MODELS Infant Mortality TIME

SOFTWARE QUALITY CONTROL Test Maintenance Code Design Analysis Spoilage Software Quality: Absence of spoilage

SOFTWARE QUALITY CONTROL Detection Rate Removal Rate Responsibility WORST BEST Tom DeMarco

Capability Maturity Model Capability Maturity Models® (CMMs®): - 1. Initial: Few processes are defined, success a function of individual effort - 2. Repeatable: Basic processes in place to repeat earlier success - 3. Defined : Processes for engineering and management are documented. - 4. Managed: Detailed metrics for software process and quality - 5. Optimizing: Peak performance

Capability Maturity Model Project Management Maturity Model - 1. Ad-Hoc: Few processes are defined, success a function of individual effort - 2 Abbreviated: Basic processes in place to repeat earlier success - 3. Organized: Processes for engineering and management are documented. - 4. Managed: Detailed metrics for software process and quality - 5. Adaptive: Peak performance

Project Human Resources and Communication Management TMGT 510 Project Human Resources and Communication Management

PROJECT MANAGEMENT Leadership!!!!

HR AND COMMUNICATION

HR AND COMMUNICATION

HR AND COMMUNICATION Resource Loading WBS COST ESTIMATES BUDGET SCHEDULE COST ESTIMATES BUDGET SW Development Code Test Document Code: $10X Test: $1x Document: $0.5x $xxx.xxx.xxx Resource Loading

HR AND COMMUNICATION ENVIRONMENT CLIMATE Other Teams Marketplace Enthusiasm STRUCTURE Competition Accountability Reward System GOALS Reporting Relationships Values Clarity Commitment Collaboration Mission Philosophy Stress Feedback System Decision Making Behavior Norm Flexibility Trust Competition Culture Involvement Pressures

MANAGING DIFFICULT PEOPLE HR AND COMMUNICATION MANAGING DIFFICULT PEOPLE   21. Bulls -- come out charging, attacking the other person, perhaps out of frustration   22. Snakes: Hides and attacks when least expected. Trying to maintain order   21. Cheetahs – Burst in sudden temper displays  22. Macaw Parrots - Talk and chatter, sometimes sense, sometimes none-sense  23. Ostriches - handle difficult situations in non-committal way  24. Cubs – humorous, friendly and cooperative. Do not reveal what they really think, leads them to make unrealistic commitments.  25. Hyenas – They lack faith on other people and wilt them with sarcasm and doubts.  26. Rhinoceroses – strong and knowledgeable whose “know-it-all” attitudes are overbearing.  27. Peacocks -- pretender they are experts, but aren’t.  28. Turkeys – cannot make a decision. Are nice, but hope situations resolve themselves.  29. Beavers – hardworking and proficient, but arouse other employees’ jealousy and suspicion.

HR AND COMMUNICATION Analyzer Ruler Intent Need Category Get it done right Control Ruler Get it done right Accuracy Analyzer Get Along Approval Relater Get Appreciated Attention Entertainer Task Oriented Analyzer Ruler Window on the World of Difficult People Entertainer Relater People Oriented Passive Aggressive

TMGT 510 RISK MANAGEMENT

PROJECT RISK MANAGEMENT User Involvement 19% Exectuive Management Support 16% Clear Requirements 15% Proper Planning 11% Realistic Expectations 10% Smaller Project Milestones 9% Competent Staff 8% Ownership 6% Clear Vision and Objectives 3% Hardworking, Focus Staff 3%

PROJECT RISK MANAGEMENT RISK CHARACTERISTICS ·       Risk is inherent to every project. Risk is a fundamental ingredient of opportunity and is a part of every project. It is the possibility, not the certainty, of bearing a loss. ·       Risk is neither intrinsically good nor bad. Risk is not something to avoid, especially because it is inherent to every project. Every risk identified is a potential opportunity. Risk is not something to fear, but something to manage. Successful teams deal with risk by recognizing and minimizing uncertainty and by proactively addressing each identified risk.

PROJECT RISK MANAGEMENT RISK MANAGEMENT PRINCIPLES Assess risks continuously throughout the project life cycle. Ongoing risk management of a project introduces a degree of resilience to change. Use risk-based decision-making. Requires that all decisions be made within the context of their risk. The team’s actions are prioritized in relationship to the status of the risk—the highest risk items should be dealt with first and incorporated into the project plan Establish some level of formality. Requires a process that is understood and used by the team. not structured, it will not be useful. Cover all key people and processes. The team must ensure that the key persons and processes are covered, or it is likely that significant risks will be missed. Treat risk identification as a positive. Team members must be willing to identify risk without fear of punishment or criticism.

PROJECT RISK MANAGEMENT Risk Management Process

PROJECT RISK MANAGEMENT IDENTIFICATION Inclusive contribution. Risk identification is best accomplished as a group effort in order to fully explore the potential risks associated with the readiness effort. ·     Premortem. Encourages the project team and any other participants to use their intuition and imagination by looking into the future and predicting what might make the project fail. Negative thinking. Applying logical but negative thinking to both the project management strategy and the rationale for sponsorship seeks to identify oversights, alternatives, conflicts, and new possibilities. Interdependencies of risks. When developing a strategy to manage risk, the readiness team should examine the relationships and dependencies among risks. A strategy to reduce risk in one area can increase risk in another. For example, a decision to reduce the risk of a lengthy project by adding team members will increase the risk of poor team coordination and miscommunication. Iterative process. Because circumstances and information may change throughout the course of the project, it is wise to discuss risk mitigation plans and history, and identify new risks with the completion of each milestone.

PROJECT RISK MANAGEMENT RISK TYPES Economic and regulatory risks. May prevent the project from delivering the expected benefits Product, market, and competitive risks. Related to the current or future issues that may arise in the marketplace. Technological risks. Include not achieving project goals because of technological failure, inadequacy, or lack of readiness. Organizational risks. When not present, minimize the return on investment of a project. These missing factors might include: a clear statement of requirements, realistic expectations, stakeholder commitment (lack of vendor or user support), executive sponsorship, project management skills and experience, communication planning and execution, rewards and recognition alignment, cultural alignment, training and education, organizational structure alignment, etc.

PROJECT RISK MANAGEMENT ORGANIZATIONAL READINESS RISKS Leadership, Represents an organization’s intent or capability to create change. Culture, Represents the set of beliefs, behaviors, and assumptions that guide people’s day-to-day activities within the organization. Individuals, Represents the employees’ competence, capacity, and resilience for dealing successfully with the IT change; Business Process, Represents the organization’s ability to execute its mission in delivering products and services to its target market or audience. Solution Development Process, Represents the organization’s ability to develop an IT solution to address specific business requirements. Operational Process, Represents the organization’s capability of maximizing the operations of its IT plans. Hardware, Represents the most tangible product of a technology change. Software, the applications designed to provide capabilities at the core of the business objectives.

PROJECT RISK MANAGEMENT IDENTIFICATION Qualitative Quantitative

PROCUREMENT MANAGEMENT TMGT 510 PROCUREMENT MANAGEMENT

PROJECT PROCUREMENT MANAGEMENT Firm Fixed Price Fixed Price + Incentive Cost + Incentive Cost + Fixed Fee Cost + % Cost Buyer Risk Seller Risk