Karolina Muszyńska Based on http://www.csun.edu/~dn58412/IS431/IS431_SP13.html Information systems in organization Information systems and their stakeholders Role of system analysts IS building blocks – focuses for information systems System development process overview Principles of system development 2 Information System (IS): People, data, processes, and information technology that interact to collect, process, store, and provide as output the information needed to support and improve operational, tactical, and strategic activities of an organization (business). Information Technology (IT): A combination of computer technology (hardware and software) with telecommunications technology (data, image, and voice networks) 3 Information Systems in Organization STRATEGIC EXECUTIVE INFORMATION SYSTEMS TACTICAL MANAGEMENT INFORMATION SYSTEMS TRANSACTION PROCESSING SYSTEMS OPERATIONAL A C C O U N T I N G F I N A N C E H U M A N R E S P R O D U C T I O N S A L E S O T H E R S VALUE CHAIN 4 Transaction Processing Systems Management Information Systems Executive Information Systems Decision Support Systems Expert Systems Functional Area Information Systems (Accounting, HR, Sales, Production …) Office Automation Systems (Personal Productivity Software) Collaboration Systems (Groupware) Enterprise Systems 5 Information System in Context 6 Stakeholder: any person who has an interest in an existing or proposed information system. Stakeholders can be technical or nontechnical workers. They may also include both internal and external workers. Information workers are those workers whose jobs involve the creation, collection, processing, distribution, and use of information. Knowledge workers are a subset of information workers whose responsibilities are based on a specialized body of knowledge. 7 Perspectives on an Information System 8 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 is to be solved ◦ They view the system in terms of cost/benefit to solve business problem 9 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 10 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 construct information systems based on the design specifications from the system designers. Their activities relate to building the COMPONENTS of the system. 11 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. 12 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 13 Working knowledge of information technology Computer programming experience and expertise General business knowledge General problem-solving skills Good interpersonal communication skills Good interpersonal relations skills Flexibility and adaptability Character and ethics Systems Analysis and Design Skills 14 Information systems architecture - a unifying framework into which various stakeholders with different perspectives can organize and view the fundamental building blocks of information systems. 15 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. 16 17 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. Directive - a new requirement that is imposed by management, government, or some external influence/parties. 18 System development process – a set of activities, methods, best practices, deliverables, and automated tools that stakeholders use to develop and continuously improve information systems and software 19 System Development Process Context 20 System initiation – the initial planning for a project to define initial business scope, goals, schedule, and budget. System analysis – the study of a business problem domain to recommend improvements and specify the business requirements and priorities for the solution. System design – the specification or construction of a technical, computer-based solution for the business requirements identified in a system analysis. System implementation – the construction, installation, testing, and delivery of a system into production. 21 System Building Blocks 22 Purpose: define perceived problems, opportunities, and directives; assess the risk of project; establish scope, preliminary requirements and constraints, participants, budget and schedule (preliminary study) Issues: Is the project worthwhile? 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 23 Purpose: to study and analyze the existing system from 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 24 Purpose: discover users’ needs or expectations out of the new system in terms of Data, Processes, and Interfaces Issue: Specify requirements for the new system (WHAT IS 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 25 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: using graphical model of a system to represent user requirements in terms of Data, Processes and Interfaces, and to facilitate improved communication between system stakeholders. Deliverable: Logical Systems Models (DFD, ERD, Use Case Diagrams, Class Diagrams, etc.) 26 Purpose: identify all candidate solutions, analyze the feasibility of each candidate, recommend a candidate system as the target solution Issue: Feasibility analysis in 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 27 Candidate solutions evaluated in terms of TOES and Risks: ◦ Technical feasibility – Is the solution technically practical? Does our staff have the technical expertise to design and build this solution? ◦ Operational feasibility – Will the solution fulfill the users’ requirements? To what degree? How will the solution change the users’ work environment? How do users feel about such a solution? ◦ Economic feasibility – Is the solution cost-effective? ◦ Schedule feasibility – Can the solution be designed and implemented within an acceptable time? ◦ Risk feasibility – What is the probability of a successful implementation using the technology and approach? (Risk Management) 28 Purpose: to transform business requirements into technical design specifications for construction Issue: HOW technology 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 Feasibility check: Continue/ Reduce or expanse the scope with budget and schedule modification 29 Purpose: to build and test a system that fulfills business requirements and design specs; implement interfaces between new and existing systems Issue: Construct database, application programs, user/system interfaces, implement software Deliverable: proposed system within budget and schedule 30 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 31 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 32 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 33 Cross life-cycle activity – any activity that overlaps many or all phases of the systems development process. ◦ Fact-finding - the formal process of using research, interviews, meetings, questionnaires, sampling, and other techniques to collect information about system problems, requirements and preferences. ◦ Documentation and presentation Documentation – the ongoing activity of recording facts and specifications for a systems for current and future reference. Presentation – the ongoing activity of communicating findings, recommendations, and documentation for review by interested users and mangers. Repository – a database and/or file directory where system developers store all documentation, knowledge, and artifacts for one or more information systems or projects. ◦ Feasibility analysis ◦ Process and project management 34 Principles of System Development 1. Get the system users involved 2. Use a problem-solving approach 3. Establish phases and activities 4. Document throughout the development 5. Establish standards 6. Manage the process and projects 7. Justify systems as capital investments 8. Don’t be afraid to cancel or revise scope 9. Divide and conquer 10. Design systems for growth and change 35 Principle 1: Get the owners and users involved in all system development phases. User Participation/Involvement creates “System Ownership” and leads to User Acceptance and User Satisfaction. Bottom line: owners and users will live with the system !!! “OUR system [owners + users + developers] will be effective, efficient, competitive, user friendly” 36 Principle 2: Use a problem solving approach ◦ Study and understand the problem in its context ◦ Define the requirements of a suitable solution ◦ Identify candidate solutions and select the best available ◦ Design and/or implement the solution ◦ Observe and evaluate the solution impact, and refine the solution accordingly 37 Principle 3: Establish phases and activities (define a process to follow) ◦ Scope definition ◦ Problem Analysis ◦ Requirement Analysis ◦ Logical Design ◦ Decision Analysis ◦ Physical Design and Integration ◦ Construction and Testing ◦ Implementation and Delivery These phases identify problems, evaluate, design, and implement solution (Systems Development Process) 38 Principle 4: Document throughout the system development process ◦ Ongoing activity to reveal strength and weakness of the system during the development process ◦ Enhance communication and acceptance among stakeholders ◦ Agreements and Contracts between Owner/User and Analyst/Designer on the Scope, Requirements, Resources of the project. 39 Principles of System Development … Principle 5: Establish standards for consistency ◦ System development standards: documentation, methodology ◦ Business standards: business rules and practices ◦ IT standards : common architecture and configuration for a consistent system development 40 Principle 6: Manage the process and projects ◦ Process management : ongoing activity that documents, manages, oversees the use of, and improves an organization’s chosen methodology (the “process”) for system development. Process management is concerned with phases, activities, deliverables, and quality standards should be consistently applied to all projects. ◦ Project management : the process of scoping, planning, staffing, organizing, directing, and controlling a project to develop an information system at a minimum cost, within a specified time frame, and with acceptable quality. 41 Principles of System Development … Principle 7: Justify Systems as Capital Investments ◦ Strategic Information System Plan fits in and supports Strategic Enterprise Plan ◦ There are several possible solutions, the first one is not necessary the best ◦ Feasibility of each solution in terms of Cost Effectiveness: Cost/benefit analysis Risk management: Identification, evaluation, and control of potential threat to the completion of a system 42 Principle 8: Don’t be Afraid to Cancel and Revise Scope: Creeping Commitment ◦ Expectation and scope of a project may be growing up ◦ Development process has checkpoints for its phases: all costs committed so far are sunk costs. Cancel the project if it is no longer feasible (ORGANIZATION) Reevaluate/adjust cost/schedule if the scope is expanding (ANALYST) Reduce the scope if budget/schedule is shrinking (ANALYST) 43 Principle 9: Divide and Conquer ◦ Divide a complex system into simpler subsystems/components ◦ Problem solving process could be simplified for smaller problems ◦ Different subsystems for different stakeholders 44 Principle 10: Design Systems for Growth and Change ◦ Changes of technology, user requirements ◦ Flexibility and adaptability should be built into the system 45