Lecture2s.ppt

UKAI 2063 Accounting Information Systems II Lecture 2 System Development Strategy  Lecture 2 Outline The business case for information systems projects Feasibility study An overview of systems development methodologies, techniques and tools Structured...

UKAI 2063 Accounting Information Systems II Lecture 2 System Development Strategy  Lecture 2 Outline The business case for information systems projects Feasibility study An overview of systems development methodologies, techniques and tools Structured approach to systems development: systems development life cycle (SDLC) and structured systems analysis and design method (SSADM) 2-2 The Business Case for Information Systems Projects  Introduction The term business case refers to the reasons, or justification, for a proposal A strong business case suggests that the company should pursue the alternative, above other options, because it would be in the firm’s best interest to do so Systems development typically starts with a systems request, followed by a preliminary investigation, which includes a feasibility study 2-4  Strategic Planning – A Framework for IT Systems Development Strategic Planning Overview SWOT analysis Porter’s Five Forces PEST analysis 2-5  Porter’s Five Forces 2-6  PEST ANALYSI S 2-7  Strategic Planning – A Framework for IT Systems Development From Strategic Plans to Business Results Mission statement Stakeholders Goals Objectives 2-8 2-9  Strategic Planning – A Framework for IT Systems Development The Future If you could look into the future, here is what you might see: new industries, products, and services emerging from amazing advances in information technology, customers who expect world-class IT support, a surge in Internet-based commerce, and a global business environment that is dynamic and incredibly challenging 2 - 10 What Is a Business Case? Should be comprehensive, yet easy to understand Should describe the project clearly, provide the justification to proceed, and estimate the project’s financial impact 2 - 11 Business Case’s Questions Why are we doing this Will we suffer a project? productivity loss What is the project during the transition? about? What is the return on How does this solution investment and address key business payback period? issues? What are the risks of How much will it cost doing the project and and how long will it not doing the project? take? What alternatives exist? How will we measure success? 2 - 12  Information Systems Projects Main Reasons for Systems Projects/Request 2 - 13  Information Systems Projects Factors that Affect Systems Projects 2 - 14  Overview of Feasibility A systems request must pass several tests, called a feasibility study, to see whether it is worthwhile to proceed further 2 - 15  Overview of Feasibility Operational Feasibility Technical Feasibility Economic Feasibility Total cost of ownership (TCO) Tangible benefits Intangible benefits Schedule Feasibility 2 - 16  Evaluating Feasibility The first step in evaluating feasibility is to identify and weed out systems requests that are not feasible Even if the request is feasible, it might not be necessary Feasibility analysis is an ongoing task that must be performed throughout the systems development process 2 - 17  Setting Priorities Factors that Affect Priority Will the proposed system reduce costs? Where? When? How? How much? Will the system increase revenue for the company? Where? When? How? How much? 2 - 18  Setting Priorities Factors that Affect Priority Will the systems project result in more information or produce better results? How? Are the results measurable? Will the system serve customers better? Will the system serve the organization better? 2 - 19  Setting Priorities Factors that Affect Priority Can the project be implemented in a reasonable time period? How long will the results last? Are the necessary financial, human, and technical resources available? Whenever possible, the analyst should evaluate a proposed project based on tangible costs and benefits that represent actual (or approximate) dollar values 2 - 20  Setting Priorities Discretionary and Nondiscretionary Projects Projects where management has a choice in implementing them are called discretionary projects Projects where no choice exists are called nondiscretionary projects 2 - 21 Preliminary Investigation Overview Preliminary investigation Interaction with Managers and Users Let people know about the investigation and explain your role Employee attitudes and reactions are important and must be considered Be careful in your use of the word problem Question users about additional capability they would like to have 2 - 22 Preliminary Investigation Overview Planning the Preliminary Investigation During a preliminary investigation, a systems analyst typically follows a series of steps The exact procedure depends on the nature of the request, the size of the project, and the degree of urgency 2 - 23  Preliminary Investigation Overview Step 1: Understand the Problem or Opportunity Step 2: Define the Project Scope and Constraints Step 3: Perform Fact-Finding Step 4: Analyze Project Usability, Cost, Benefit, and Schedule Data Step 5: Evaluate Feasibility Step 6: Present Results and Recommendations to Management 2 - 24  Step 1: Understand the Problem or Opportunity Reason to understand the problem? Changes will have unexpected effect on another system Popular technique to investigate cause and effect is called the fishbone diagram or Ishikawa diagram – to uncover the root causes of a problem rather than the symptoms 2 - 25 2 - 26  Step 2: Define the Project Scope and Constraints Define the boundaries – systems, people and business processes that will be affected To avoid unnecessary expenditure of time and money Constraint is that the system must achieve eg. the system must operate with existing hardware Present vs. future (system must be met) Internal vs. external (constraint from gov) Mandatory vs. desirable 2 - 27  Step 3: Perform Fact- Finding Analyse organisation charts Interviews (1. determine the people to interview, 2. establish objective, 3. develop interview questions, 4. prepare for the interview, 5. conduct the interview, 6. document, 7. evaluate the interview). Open- ended question Review current documentation Observation Questionnaire Analyse data (Pareto chart & scatter diagram) 2 - 28  Step 4: Analyze Project Usability, Cost, Benefit, and Schedule Data Gathered data about the project’s predicted costs, anticipated benefits and schedule issues that could affect implementation 2 - 29  Step 5: Evaluate Feasibility Operational feasibility (review of problems and way to resolve) Technical feasibility Economic feasibility Schedule feasibility 2 - 30  Step 6: Present Results and Recommendations to Management A report to management 2 - 31  Overview of systems development methodologies, techniques and tools Some reasons why systems development failed A lack of ownership of and commitment to the system from users, as a result of the low level of involvement. Do not satisfy business requirements or requirements could have been mis-understood. Business requirements could have changed between inception and delivery. Inadequate analysis and design tools and techniques could have been used. Cause extensive maintenance requirements and thus an increase in the applications backlog. Or more likely a combination of these problems. 2 - 33  To improve systems success Business managers should:  Align the interests of system developers and the managers who must implement information systems.  Initiate serious review of the proposed system design concept and plans for achieving system use and value.  Make thorough system investment decisions by measuring and managing system use and value. Source: Markus and Keil (1994) 2 - 34  To improve systems success Systems specialists should:  Accept responsibility for system use, not just systems.  Focus on the system design concept in addition to user requirements and, wherever possible, propose multiple design concepts.  Employ user-participation strategies as a way to get a good design concept. Source: Markus and Keil (1994) 2 - 35  Systems methodology A systems development methodology is a recommended means to achieve the development, or part of the development, of information systems based on a set of rationales and an underlying philosophy that supports, justifies and makes coherent such as recommendation for a particular context. The recommended means usually includes the identification of phases, procedures, tasks, rules, techniques, guidelines, documentation and tools. They might also include recommendations concerning the management and organization of the approach and the identification and training of the participants. 2 - 36 Source: Avison and Fitzgerald (2003)  Examples of systems methodology JSD Extreme programming JAD (XP) (good software SSADM practices p20) IE OOAD SSM RUP Multiview ( several CASE competing Spiral methodologies) Waterfall RAD ETHICS (Social DSDM Technical systems OMT development P20) XP – http://www.extremeprogramming.org DSDM - http://www.dsdm.org 2 - 37  Systems technique Specific techniques the systems analysis and design teams follow to ensure the outputs are clear, accurate and complete, e.g. DFD, ERD, and rich picture. A technique is a way of doing a particular activity in the information systems development process, and any particular methodology may recommend techniques to carry out many of these activities. Each technique may involve the use of one or more tools. 2 - 38  Examples of systems technique Rich pictures Structured Root definitions walkthroughs Conceptual models Object orientation Entity modelling UML Relational modelling PERT charts Normalization Gantt charts Dataflow diagramming Joint application Entity life History development (JAD) 2 - 39  Systems tool Tools are normally software to help the development of an information system, e.g. CASE, Systems Architect, Ms- Project These tools might enable some development task to be done automatically or semi-automatically. 2 - 40 Examples of systems tool Project management: MS Project Web site development: Dreamweaver Drawing: Microsoft Visio Database management system: Microsoft Access, MySQL, DBMS 2 - 41  How systems methodology helps? To record accurately the requirements for an information systems and to reduce the chances of mis-understanding the requirements. To provide a systematic method of development so that progress can be effectively monitored. To introduce best practice techniques to the analysis and design process. 2 - 42  How systems methodology helps? To produce an information system within an appropriate time limit and at an acceptable cost. To produce a system which is well documented and easy to maintain. To provide an indication of any changes that need to be made as early as possible in the development process. To provide a system that is liked by those people affected by that system. 2 - 43  Features of systems methodology A methodology can range from being a fully-fledged product detailing every stage and task to be undertaken to being a vague outline of the basic principles in a short pamphlet. A methodology can cover widely differing areas of the development process, from high-level strategic and organizational problem solving to the details of implementing a small computer system. 2 - 44  Features of systems methodology A methodology can range from being designed to be A methodology can range from being designed to be applicable to specific types of problem in certain types of environment or industry to an all- encompassing general-purpose methodology. A methodology may be potentially usable by anybody or only by highly trained specialists or be designed for users to develop their own applications. A methodology may require an army of people to perform all the specific tasks or it may not even have any specified tasks. A methodology may or may not include tools and toolsets. 2 - 45  So many methodologies, which is the best? There is no benefit to be gained from attempting to find, in isolation, a “best” methodology. There should be a search for an appropriate methodology in the context of the problems being addressed, the applications and the organization and its culture. 2 - 46 What context? You might ask… _|_______________|_______________|_____ uctured Unstructured “We have 20 bank branches in Kuala Lumpur; all branches combined there are 5,000 deposits made on each working day. We keep details about each deposit, e.g. customer A/C number, amount deposit, and so on.” “We need a new web portal to allow customers to buy groceries online.” 2 - 47  Five different classes of situation and appropriate Situation approaches Systems development Approaches 1 Well- A traditional SDLC structured approach might be problem regarded as appropriate situations with in this class of situation a well-defined problem and clear requirements 2 As above but Source: Avison and Taylor (1996) Data, process modelling, 2 - 48  Five different classes of situation and appropriate approaches Situation Systems development Approaches 3 Unstructured A soft systems problem approach would be situation with appropriate in this unclear situation. objectives. 4 High user- A people-focused iteration approach, for example, systems. ETHICS would be appropriate here. 5 Avison Source: Veryandunclear Taylor (1996) A contingency 2 - 49  Systems Development Life Cycle  Systems Development Life Cycle (SDLC) The traditional SDLC is one of the earliest methodologies to systems development. It was developed by Royce in 1970. The SDLC consists of phases that are an organised way of progressing through the IS development, using specific techniques and tools. 2 - 51  Systems Development Life Cycle (SDLC) A waterfall model: outputs from one phase feed into next phase. The SDLC phases and their activities should be tailored for each specific IS development. A large number of SDLC models exist, however all contain minor variations to break up the basic cycle of IS development (Conceptual Framework), i.e. analysis, design, development and implementation. 2 - 52  Conceptual Framework of SDLC Stages Analysis Implementation Design Development 2 - 53 Other View of SDLC Stages 2 - 54 Other View of SDLC Stages 2 - 55 In this unit, we will follow the one by Shelley & Cashman (2010) Phases of the SDLC System Planning Systems Analysis Systems Design Systems Implementation Systems Support & Security 2 - 56 SDLC Stages 2 - 57  Phases of SDLC Systems Planning Systems planning phase Systems request – begins the process & describes problems or desired changes Purpose of this phase is to perform a preliminary investigation Key part of preliminary investigation is a feasibility study Output: Feasibility report containing problem definition and objective summaries from which management can make a decision on whether to proceed with the proposed project 2 - 58  Phases of SDLC Systems Analysis To understand how users accomplish their work when interacting with a computer; and begin to know how to make the new system more useful and usable. To understand how the business functions and have complete information on the people, goals, data and procedure involved Learn the who, what, where, when, how, and why of the current system Fact finding techniques includes: Interviewing Sampling and investigating hard data Questionnaires Observe the decision maker’s behavior and environment Output: Deliverable is the System requirements document 2 - 59  Phases of SDLC Systems Design Create physical model Design user interface, identify necessary outputs, inputs, and processes Design internal/ external controls Determine application architecture Output: System design specification 2 - 60  Phases of SDLC Systems Implementation New system is constructed Programs written, tested, and documented, and the systems is installed Converting to new system User training Output: Complete functioning system 2 - 61  Phases of SDLC Systems Support & Security Maintenance, enhancement and protecting the system occurs at this phase Maximise return on the IT investment A well-designed system must be secure, reliable, maintainable, and scalable Output: Operational information systems 2 - 62  A Structured Systems Analysis and Design Method (SSADM)  Structured Systems Analysis and Design Method (SSADM) Originally developed by the UK consultant Learmonth and Burchett Management Systems (LBMS) and Central Computing and Telecommunications Agency (CCTA)** to standardise development process in the government departments. SSADM has gone through a number of changes since its original publication with the last version being issued in 1996 as 'SSADM 4+ version 4.3‘. By the mid-1990s SSADM was the most widely-used application development methodology in Europe, with over 5,000 certified practitioners. ** As from 1st April 2001, CCTA became an integral part of the Office of Government Commerce (www.ogc.gov.uk) 2 - 64 Areas covered by SSADM Analysis of the current business procedures and organization to see how a new system will best fit into them. Analysis of any system (automated or manual) that covers the same or similar functions to those for the new system to ascertain how they work and what could be done to improve them. Analysis and design of the data requirements for the new system including any ad-hoc reporting required from it. 2 - 65 Areas covered by SSADM Analysis and design of the processing required to enable the data to be captured, manipulated, stored and then reported on. Analysis and design of the interface required to support the user when working with the new system. First-cut design for the database of the new system and the physical processes required to access the data. 2 - 66 SSADM Structure Feasibility Study Requirements Analysis Requirements Specification Logical System Specification Physical Design 2 - 67  SSADM Structure SSADM adopts the waterfall model of systems development, where each stage has to be completed and signed off before subsequent stages can begin. SSADM 4+ has seven stages within a five- module framework, each with its own set of plans, timescales, controls, and monitoring procedures. SSADM does not cover the implementation and maintenance stages, treating them as installation-specific. 2 - 68  Major Tools of SSADM Logical Data Modelling Data Flow Modelling Entity /Event Modelling 2 - 69  Acknowledgements This PowerPoint presentation contains materials complied from various sources. Credits are hereby given to their respective owners. Please refer to the reading list for details. Reminder The lecture slides serve only as a quick learning guide. Students are required to refer to the main textbook for detailed elaboration. 2 - 70