1. Designing and Developing Decision Support Systems Chapter 4

2. 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?

3. 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

4. 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.

5. 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

6. 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

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

8. 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

9. 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

10. 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

11. 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

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

13. 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 http://www.sims.berkeley.edu:8000/course s/is208/s02/ReqsDoc.pdf)

14. 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

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

16. 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

17. Waterfall model Requirements Design Development Implementation Verification Maintenance

18. 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

19. 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

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

21. 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

23. 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

24. 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

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