Designing and Developing Decision Support Systems Chapter 4

Chapter overview Understand the decision process What type of DSS will it be? Decide on what to focus Redesign Business process Determine requirements Make or buy the system? What development approach to use? How to manage the project?

Understand the decision process Diagnosis of current decision making process Collect data by interviewing, observation, or historical records Describe the decision process Specify a norm for how decisions SHOULD be made There can be limitations to the process May use an Audit plan Determine what type of DSS it is going to be Focus changes depending on what type of DSS it will be Redesign business processes to include new DSS

DSS Audit plan 1.Define the decisions. Identify a primary contact. 2.Examine the formal design of the decision process. 3.Examine the actual use of the decision process. 4.Assess performance of the actual decision process. 5.Reporting and recommendations.

Decide on what type of DSS will it be? Communication-driven DSS Data-driven DSS Document-driven DSS Knowledge-driven DSS Model-driven DSS. Will it be a combination of the types? Focus varies depending on the type of DSS

Focus and types of DSS Model driven DSS –Uses a statistical, financial, optimization, or simulation model. –Parameters are provided by the user Prior assumptions are stated (about distributions of data or relationships between variables) Diagnosis of decision making focuses on assumptions

Focus and types of DSS Data driven DSS emphasizes access to and manipulation of large amounts of structured data Mostly presents data in different formats Examples: Management reporting systems, Executive information systems, data warehousing systems Focus is on Critical Success Factors

Critical success factors Short list of factors that are critical to the success of the organization Find out by interviewing the executives Based on the CSF, determine what Key Performance Indicators must be included in the outputs –E.g. Customer satisfaction, market share Base the design and development process on these KPI’s

Redesign business process New decision process might require new business processes Based on the analysis recommend changes in the business process Tradeoff between what processes will the DSS support – existing or new ones Business process redesign is difficult for organizations

Requirements Document Describes what the software will do (not how it will do it) It is a written document An agreement between the developers and the intended users Must have for projects that take longer than 1 month, involve more than one developer and more than one set of users

Parts of a Requirements Document Part I – Application overview Objectives Business processes and how this application will be used User roles and responsibilities Interaction with other systems Terminology used

Parts of a Requirements Document Part II – Functional Requirements Functionality –Process requirements, and data requirements Performance Usability Concurrency requirements

Requirements document Document must be READ by people Update the document based on feedback Record what, who, when, why and how of feedback (Requirements Document Notes is based on s/is208/s02/ReqsDoc.pdf)

Feasibility study Is it worth going forward with the solution Financial feasibility (Benefits and costs) –Money, time, human resources Advantages and disadvantages Technical feasibility Anticipated impacts Timeframe and workplan Leads to Make or Buy decision

Choice of methods for development Systems Development Lifecycle (Waterfall model) Prototyping End-user development Outsourcing

SDLC Waterfall model Seven distinct steps 1.Requirements specification 2.Design 3.Construction (aka: implementation or coding) 4.Integration 5.Testing and debugging (aka: verification) 6.Installation 7.Maintenance

Waterfall model Requirements Design Development Implementation Verification Maintenance

Waterfall model Purely sequential Sign-off at each stage Little chance to revise requirements Suitable for large, mission critical applications Inability to revise requirements is a major problem Projects cancelled at later stages – huge losses

Prototyping Basic requirements, not detailed ‘Quick and dirty’ prototype Client reviews More requirements Refine prototype Client reviews Reduced costs than traditional method Rapid Application Development (RAD) tools help

Prototyping Requirements gathering Identify objectives, Functionality and performance requirements Develop Prototype User demo and testing ProductionDeployment

Spiral model Proposes to resolve the problem of run- away projects Feasibility evaluated more frequently Iterative method Multiple phases – each beginning with design goals and ends with review by clients

End user development User is also the developer Single user systems Fast, and to the user’s specifications User may not use proper development techniques / tools May have many errors in design User may need extensive support from IT people May not be systematic

Project Management Completing the project on time within budget On-time delivery of deliverables Project team –From many different areas –Users, project manager, staff, analysts, sponsors, specialists

Read “MIDS at Lockheed” case study for discussion in class