Systems Analysis & Design Methods

1. IS 630 : Accounting Information Systems http://www.csun.edu/~dn58412/IS630/IS630_F13.htm Systems Analysis & DesignMethods Lecture 9

2. Systems Development Life Cycle (SDLC) • Systems Development Life Cycle (SDLC) methodology: formalized, standardized, documented set of activities (Systems Development Process) used to manage a systems development project. IS 630 : Lecture 9

3. Perspectives on an Information System IS 630 : Lecture 9

4. System Owners • System owners – an information system’s sponsors and executives advocate, usually responsible for funding the project of developing, operating, and maintaining the information system. They define the SCOPE of a system: what business problem to be solved • They view the system in term of cost/benefit to solve business problem IS 630 : Lecture 9

5. System Users • System users – use or are affected by an information system on a regular basis – capturing, validating, entering, responding to, storing, and exchanging data and information. They define the REQUIREMENTS of the system. • Internal users • Clerical and service workers • Technical and professional staff • Supervisors, middle managers, and executive managers • Remote and mobile users (internal but disconnected) • External users IS 630 : Lecture 9

6. SystemDesignersandSystemBuilders • System designers translate system users’ business requirements and constraints into technical solution: computer databases, inputs, outputs,networks, and software meeting the system users’ requirements. Their activities relate to the DESIGN of a system • System builders constructs information systems based on the design specifications from the system designers. Their activities relate to building the COMPONENTS of the system. IS 630 : Lecture 9

7. Systems Analysts • Systems analysts study the problems and needs of an organization to determine how people, data, processes, and information technology can best accomplish improvements for the business. They are FACILITATORS of the system development project. • A programmer/analyst (or analyst/programmer) includes the responsibilities of both the computer programmer and the systems analyst. • A business analyst focuses on only the nontechnical aspects of systems analysis and design. IS 630 : Lecture 9

8. The Systems Analyst as a Problem-Solver • What “problems” to solve: (Project Definition) • True problem situations, either real or anticipated, that require corrective action • Opportunities to improve a situation despite the absence of complaints • Directives to change a situation regardless of whether anyone has complained about the current situation • Why: (Project Justification) • Effective: Do right thing • Efficient: Do thing right • Competitive: Do thing differently IS 630 : Lecture 9

9. Accountant’s Involvement in AIS Development/Acquisition • User • Analyst • Purchaser • Implementer • Consultant • Internal Auditor • External Auditor IS 630 : Lecture 9

10. Focuses for Information Systems • KNOWLEDGE (Data) — the raw material used to create useful information. • PROCESSES— the activities (including management) that carry out the mission of the business. • COMMUNICATION (Interfaces)— how the system interfaces with its users and other information systems. IS 630 : Lecture 9

11. IS 630 : Lecture 9

12. KNOWLEDGE Focus • System owners’ view • Interested not in raw data but in information that adds new business knowledge and information that help managers make intelligent decisions. • Data entities and business rules. • System users’ view • Something recorded on forms, stored in file cabinets, recorded in books and binders, organized into spreadsheets, or stored in computer files and databases. • Focus on the business issues as they pertain to the data. • Data requirement – a representation of users’ data in terms of entities, attributes, relationships, and rules independent of data technology. IS 630 : Lecture 9

13. KNOWLEDGE Focus . . . • System designers’ view • Data structures, database schemas, fields, indexes, and constraints of particular database management system (DBMS). • System builders’ view • SQL • DBMS or other data technologies IS 630 : Lecture 9

14. PROCESS Focus • System owners’ view • concerned with high-level process called business functions • Business function – a group of related processes that support the business. Functions can be decomposed into other subfunctions and eventually into processes that do specific tasks. (e.g.Sales Function) • A cross-functionalinformation system – a system that supports relevant business processes from several business functions without regard to traditional organizational boundaries such as divisions, departments, centers, and offices. (e.g. Production Function) IS 630 : Lecture 9

15. PROCESS Focus . . . • System users’ view • concerned with work that must be performed to provide the appropriate responses to business events. • Business processes – activities that respond to business events. • Process requirements – a user’s expectation of the processing requirements for a business process and its information systems. • Policy – a set of rules that govern a business process. • Procedure – a step-by-step set of instructions and logic for accomplishing a business process. • Work flow – the flow of transactions through business processes to ensure appropriate checks and approvals are implemented. IS 630 : Lecture 9

16. PROCESS Focus . . . • System designers’ view • Concerned with which processes to automate and how to automate them • Constrained by limitations of application development technologies being used • Software specifications – the technical design of business processes to be automated or supported by computer programs (off-shelf, in-house) to be written by system builders. IS 630 : Lecture 9

17. PROCESS Focus . . . • System builders’ view • Concerned with programming logic that implements automated processes • Application program – a language-based, machine-readable representation of what a software process is supposed to do, or how a software process is supposed to accomplish its task. • Prototyping – a technique for quickly building a functioning, but incomplete model of the information system using rapid application development tools. IS 630 : Lecture 9

18. COMMUNICATION Focus • System owners’ view • Concerned with communications scope of an information system. • Who (which business units, employees, customers, and partners) must interact with the system? • Where are these business units, employees, customers, and partners located? • What other information systems will the system have to interface with? • System users’ view • Concerned with the information system’s inputs and outputs (Interface Requirements). IS 630 : Lecture 9

19. COMMUNICATION Focus . . . • System designers’ view • Concerned with the technical design of both the user and the system-to-system communication interfaces. • Interface specifications – technical designs that document how system users are to interact with a system and how a system interacts with other systems. • User dialogue – a specification of how the user moves from window to window or page to page, interacting with the application programs to perform useful work. • System builders’ view • Concerned with the construction, installation, testing and implementation of user and system-to-system interface solutions. • Middleware – utility software that allows application software and systems software that utilize differing technologies to interoperate. IS 630 : Lecture 9

20. A  Meeting Transcript • System Developer: • “Iam going to build a P2P system [???] with killer apps in PHP and CCC [???] running on cutting-edge technologies DSL and XYZ [???].” • System Owner/User: • “Would YOUR system solve MY problem [in singular] or it just introduce YOUR %&$# [unprintable term / bleep] technology and leave ME to figure out the solutions for new problems [in plural] created by YOU &%$# &c&c… [again, longer and stronger unprintable terms / louder bleep-bleep-bleep] ? ” IS 630 : Lecture 9

21. Principles of System Development • Get the system users involved. • Use a problem-solving approach. • Establish phases and activities. • Document throughout the development. • Establish standards. • Manage the process and projects • Justify systems as capital investments. • Don’t be afraid to cancel or revise scope. • Divide and conquer. • Design systems for growth and change. IS 630 : Lecture 9

22. Where Do Systems Development ProjectsCome From? • Problem – an actual undesirable situation that prevents the organization from fully achieving its purpose, goals, and/or objectives. • Opportunity – a chance to improve the organization even in the absence of an identified problem (using PIECES framework). • Directive - a new requirement that is imposed by management, government, or some external influence/parties. IS 630 : Lecture 9

23. Where Do Systems Development Projects Come From? • Planned Projects • An information systems strategyplan has examined the business as a whole to identify those system development projects that will return the greatest strategic (long-term) value to the business • A business process redesign has thoroughly analyzed a series of business processes to eliminate redundancy and bureaucracy and to improve efficiency and value added. Now it is time to design/redesign the supporting information system for those redesigned business processes. IS 630 : Lecture 9

24. Where Do Systems Development Projects Come From? • Unplanned projects • Triggered by a specific problem, opportunity, or directive that occurs in the course of doing business. • Steering committee – an administrative body of system owners and information technology executives that prioritizes and approves candidate system development projects. • Backlog – a repository of project proposals that cannot be funded or staffed because they are a lower priority than those that have been approved for system development. IS 630 : Lecture 9

25. Systems Development Objectives • To ensure the information system satisfies an organization’s informational and operational needs (product-oriented objective). • To develop/acquire an information system in an efficient and effective manner (process-oriented objective). IS 630 : Lecture 9

26. PIECES Framework for Systems Improvement P the need to improve performance I the need to improve information(and data) E the need to improve economics, control costs, or increase profits C the need to improve control or security E the need to improve efficiency of people and processes S the need to improve service to customers, suppliers, partners, employees, etc. (They are Opportunities for New System Development Projects) IS 630 : Lecture 9

27. Characteristics of a Systems Development Methodology • Divide project into identifiable processes, each having a starting and ending point. • Produce deliverables to monitor process. • Require signoffs. • Test system before implementation. • Conduct training. • Use program change controls. • Conduct post-implementation review. IS 630 : Lecture 9

28. Classic Project Phases IS 630 : Lecture 9

29. 1. Scope Definition • Purpose: define perceived problems, opportunities, and directives (POD); assess the risk of project; establish scope, preliminary requirements and constraints, participants, budget and schedule (preliminary study) • Issues: Is the project worthwhile? (using PIECES framework) Define the scope of project • Deliverable: Project charter/plan • Feasibility check: Cancel project / Approve to continue / Reduce or expanse the scope with budget and schedule modification IS 630 : Lecture 9

30. 2. Problem Analysis • Purpose: to study and analyze the existing systemfrom the users’ perspectives as they see Data, Processes, and Interfaces • Issue: Cost/benefits of building new system to solve these problems • Deliverable: system improvement objectives (business criteria to evaluate the new system) • Feasibility check: Cancel project / Approve to continue / Reduce or expanse the scope with budget and schedule modification IS 630 : Lecture 9

31. 3. Requirement Analysis • Purpose: discover users’ needs or expectations out of the new systemin terms of Data, Processes, and Interfaces • Issue: Specify requirements for the new system (WHAT TO BE DONE) without prematurely expressing technical details (HOW) • Errors and omissions in requirement analysis result in user dissatisfaction of final system and costly modifications • Deliverable: business requirements statement IS 630 : Lecture 9

32. 4. Logical Design • Purpose:translating business user requirements into a system model that depicts only WHAT TO DO without specifying any possible technical design or implementation of those requirements (conceptual design). • Issue: usinggraphical model of a system to represent user requirements in terms of Data, Processes and Interfaces, and to facilitate improved communication between system stakeholders. • Caution: Analysis paralysis – excessive system modeling dramatically slows progress toward implementation of the intended system solution. • Deliverable: Logical Systems Models (DFD, ERD etc) IS 630 : Lecture 9

33. 5. Decision Analysis • Purpose: identify allcandidate solutions, analyze the feasibility of eachcandidate, recommend a candidate system as the target solution • Issue: Feasibility analysisin terms of technical, operational, economic, schedule (TOES), and risk • Deliverable: approved system proposal • Feasibility check: Cancel project / Approve system proposal with budget and schedule modification / Reduce the scope of proposed solution with budget and schedule modification IS 630 : Lecture 9

34. 6. Physical Design • Purpose: to transform business requirements into technical design specifications for construction • Issue: HOWtechnology will be used to build the system in terms of Data, Processes,and Interfaces • Design by Specifications vs. Design by Prototyping • Deliverable: System design specifications (blueprints) • Feasibility check: Continue/ Reduce or expanse the scope with budget and schedule modification IS 630 : Lecture 9

35. 7. Construction Phase • Purpose: to build and test a system that fulfill business requirements and design specs; implement interfaces between new and existing systems • Issue: Construct database, application programs, user/system interfaces, implement purchased or leased software • Deliverable: proposed system within budget and schedule IS 630 : Lecture 9

36. 8. Implementation Phase • Purpose: deliver the production system into operation • Issue: Train users, write manuals, load files, populate database, final test • Conversion plan: parallel systems, switch point • Deliverable: system up and running IS 630 : Lecture 9

37. Operation and Support • Ongoing system support would be provided until the system becomes obsolete and is replaced by a new one • Issues: technical support for user, fixing bugs, recovering plan, adapt to emerging requirements • When a system has reached entropy, new project for new system should be initiated IS 630 : Lecture 9

38. Summary: Systems Development Process • Scope Definition Phase: What Business Problem • Problem Analysis Phase: What System Issues (Info/Data, Processes, Communications/Interfaces) • Requirement Analysis Phase: What User Needs • Logical Design: Conceptual Model – What to Do • Decision Analysis Phase: What Solution • Design Phase: Physical Model: How to Do • Construction Phase: Do It • Implementation Phase: Use It IS 630 : Lecture 9

39. Systems Development Process In Practice IS 630 : Lecture 9

40. Model-driven Development IS 630 : Lecture 9

41. Rapid Application Development IS 630 : Lecture 9

42. Commerce Application Package • Commercial application package – a software application that can be purchased and customized to meet the business requirements of a large number of organizations or a specific industry. A synonym is commercial off-the-shelf (COTS) system. • Request for proposal (RFP) for all potential vendors • Request for quotation (RFQ) for some selected vendors • Gap analysis – a comparison of business and technical requirements against the capabilities and features of a specific commercial application package for the purpose of defining the requirements that cannot be met. IS 630 : Lecture 9

43. System Analysis & Design Approaches • DEVELOPMENT • Modeling • Prototyping (RAD) • IMPLEMENTATION • Build (In-house) • Buy (COTS) IS 630 : Lecture 9

44. Feasibility Analysis … • Technical feasibility is a measure of the practicality of a specific technical solution and the availability of technical resources and expertise. • Operational feasibility is a measure of how well the solution will work in the organization. It is also a measure of how people feel about the system/project. • Economic feasibility is a measure of the cost-effectiveness of a project or solution. • Schedule feasibility is a measure of how reasonable the project timetable is. • Risk feasibility – What is the probability of a successful implementation using the technology and approach? (Risk Management) IS 630 : Lecture 9

45. Costs and Benefits • Direct costs (benefits): directly attributable to the system or the system change. • Direct costs include equipment purchased, personnel salaries, site preparation, and materials and supplies. • Direct benefits include items such as reduced personnel and hardware costs, and improved data reliability. IS 630 : Lecture 9

46. Costs and Benefits . . . • Indirect costs (benefits): not directly attributable to the system or the system change. • Indirect costs are those that we would normally associate with overhead expenses, such as personnel fringe benefits and utilities. • Indirect benefits are perhaps the most difficult to quantify. An example of an indirect benefit is increased revenue resulting from improved customer support; such benefits are extremely difficult to measure. IS 630 : Lecture 9

47. Costs and Benefits . . . • Tangible costs (benefits): can be reasonably quantified. • Costs include software purchases and insurance • Benefits include reduced equipment costs and increased revenue. • Intangible cost (benefit): cannot be reasonably quantified. • Costs include productivity loss caused by low employee morale. • Benefits may accrue from improved information. IS 630 : Lecture 9

48. Costs and Benefits . . . • Nonrecurring costs,such as those for systems development, are incurred only once to get the system operational. • Recurring costs, such as those for equipment rental, occur throughout all or most of the system’s life. IS 630 : Lecture 9

49. Costs for a Proposed Systems Solution IS 630 : Lecture 9

50. Economic Feasibility • Payback Analysis • Payback analysis is to determine if and when an investment will pay for itself. • Payback period is the period of time that will lapse before accrued benefits overtake accrued and continuing costs. • Net Present Value • a dollar today is worth more than a dollar one year from now • Discount rate – a percentage that the business earns on investing money in other projects or investments: opportunity cost • Return-on-Investment (ROI) Analysis • Lifetime ROI = (estimated lifetime benefits – estimated lifetime costs) / estimated lifetime costs • Annual ROI = lifetime ROI / lifetime of the system IS 630 : Lecture 9