Chapter 1: Introduction to Systems Analysis and Design PDF
Document Details
Uploaded by SimplestIridium168
Al-Imam Muhammad Ibn Saud Islamic University
Tags
Related
- SUT 4.1 Stakeholders and Drivers of Information Systems PDF
- Systems Analysis And Design In A Changing World Chapter 1 PDF
- Systems Analysis and Design Chapter 1 PDF
- Introduction to Systems Analysis and Design IS 335 PDF
- Modern Systems Analysis and Design 10th Edition PDF
- Kendall & Kendall Systems Analysis and Design, 9e PDF
Summary
This document presents an introduction to systems analysis and design, a critical aspect of information systems. The content centers on the systems development lifecycle (SDLC), outlining various methodologies, and particularly highlights object-oriented analysis and design (OOSAD).
Full Transcript
Kingdom of Saudi Arabia Ministry of Higher Education Al-Imam Muhammad Ibn Saud Islamic University College of Computer and Information Sciences Chapter 1: Introduction to Systems Analysis and Design IS 335 Systems Analysis and Design Information S...
Kingdom of Saudi Arabia Ministry of Higher Education Al-Imam Muhammad Ibn Saud Islamic University College of Computer and Information Sciences Chapter 1: Introduction to Systems Analysis and Design IS 335 Systems Analysis and Design Information Systems Department Learning Objectives Be familiar with the different roles played by and the skills of a systems analyst. Understand the fundamental systems development life cycle and its four phases. Understand the evolution of systems development methodologies. Be familiar with the fundamental principles of object‐oriented systems analysis and design. Be familiar with the Unified Process, its extensions, and the Unified Modeling Language. Be familiar with the basic characteristics of object‐oriented systems. IS Department 2 Introduction System Analysis: The of understanding and specifying in detail what the information system should do. System Design: The process of specifying in detail how the many components of the information system should be physically implemented. IS Department 3 Introduction Systems Development Life Cycle (SDLC): is the process of understanding how an information system (IS) can support business needs by designing a system, building it, and delivering it to users. The key person in developing a system is the systems analyst. Systems Analyst: who analyzes the business situation, identifies opportunities for improvements, and designs an information system to implement them. IS Department 4 Introduction Why do we need a formal process? Failures occur (too) often Creating systems is not intuitive Projects are late, over budget or delivered with Fewer features than planned The System Analyst is the key person Designs a system to add value Must understand the business processes Job is rewarding, yet challenging Requires specific skill sets IS Department 5 The Systems Analyst: Skills Agents of change Identify ways to improve the organization Motivate & train others Skills needed: Technical: must understand the technology Business: must know the business processes Analytical: must be able to solve problems Communications: technical & non-technical audiences Interpersonal: leadership & management Ethics: deal fairly and protect confidential information IS Department 6 The Systems Analyst: Roles IS Department 7 Systems Development Life Cycle (SDLC) Planning Implementation Analysis Design IS Department 8 The SDLC Process The process consists of four phases Each phase consists of a series of steps Each phase is documented (deliverables; specific documents and files that provide understanding about the project) Phases are executed sequentially, incrementally, iteratively or in some other pattern IS Department 9 Questions to be Answered Planning phase Why should we build this system? What value does it provide? How long will it take to build? Analysis phase Who will use it? What should the system do for us? Where & when will it be used? Design phase How should we build it? IS Department 10 SDLC: The Planning Phase 1. Project Initiation Develop/receive a system request Conduct a feasibility analysis Technical feasibility Economic feasibility Organizational feasibility 2. Project Management Develop the work plan Staff the project Monitor & control the project IS Department 11 SDLC: The Planning Phase System Request IS Department 12 SDLC: The Analysis Phase 1. Develop an analysis strategy Model the current system Formulate the new system 2. Gather the requirements Develop a system concept Create a business model to represent: Business data Business processes 3. Develop a system proposal IS Department 13 SDLC: The Design Phase 1. Develop a design strategy 2. Design architecture and interfaces 3. Develop databases and file specifications 4. Develop the program design to specify: What programs to write What each program will do IS Department 14 SDLC: The Implementation Phase 1. Construct the system Build it (write the programming code) Test it 2. Install system Train the users 3. Support the system (maintenance) IS Department 15 SDLC: Methodologies Methodology: a formalized approach to implementing the SDLC(i.e., it is a list of steps and deliverables). Elements of the system(type) Categories Process centered , Data centered , Object-oriented Structured Amount of time and Rapid action development effort Agile development Object‐oriented systems analysis and design. DevOps, and custom methodologies. IS Department 16 Classes of Methodologies Structured Development Waterfall Development Parallel Development Rapid Application Development Phased Prototyping Throwaway Prototyping Agile Development eXtreme Programming SCRUM IS Department 17 Structured Development Waterfall Model + sys requirements are identified + minimize change -Design must be completely specified before programming -Long time between analysis and delivery IS Department 18 Structured Development Parallel Model + less time, less chance of required rework - Long documentation like waterfall - Interdependent subproject - Requires integration IS Department 19 identifies the overall system concept, and RAD Development the project team, users, and system sponsor then categorize the Phased Model requirements into a series of versions +Use CASE, JAD, Visual programming, automatic code generation to speedup + quick delivery of a functional system - Managing expectation - User might get frustrated IS Department 20 RAD Development Prototyping_Based Methodology a quick-and-dirty program that provides a minimal amount of features + very quick + less paper work - problem for complex design - short analysis phase IS Department 21 RAD Development Throwaway Prototyping_Based Methodology + long analysis, so more stable and reliable - may take more time than prototype IS Department 22 Agile Development Focus on streamlining the systems development process by eliminating much of the modeling and documentation overhead and the time spent on those tasks. Agile methodologies are not for everyone Use an agile process if your project involves Unpredictable or dynamic requirements Responsible and motivated developers Customers who understand the process and will get involved Two of the more popular examples of agile development methodologies are extreme programming (XP) and Scrum IS Department 23 Agile Development eXtreme Programming Founded on four core values: communication, simplicity, feedback, and courage. IS Department 24 Which Methodology to Use? IS Department 25 Characteristics of Object-Oriented Systems Classes & Objects Object (instance): instantiation of a class Attributes: information that describes the class State: describes its values and relationships at a point in time Methods & Messages Methods: the behavior of a class Messages: information sent to an object to trigger a method (procedure call) IS Department 26 Characteristics of Object-Oriented Systems (cont.) Encapsulation & information hiding Encapsulation: combination of process & data Information hiding: functionality is hidden Inheritance General classes are created (superclasses) Subclasses can inherit data and methods from a superclass IS Department 27 Characteristics of Object-Oriented Systems (cont.) Polymorphism & dynamic binding Polymorphism: the same message can have different meanings Dynamic binding: type of object is not determined until run-time Contrast with static binding IS Department 28 Characteristics of Object-Oriented Systems (cont.) IS Department 29 Characteristics of Object-Oriented Systems (cont.) IS Department 30 object‐oriented analysis and design (OOSAD) It is a third category of information systems development methodologies. Attempts to balance data and process Utilizes the Unified Modeling Language (UML) and the Unified Process Characteristics of OOSAD: Use-case Driven Architecture Centric Iterative and Incremental IS Department 31 Object-Oriented Systems Analysis & Design Use-case driven Use-cases define the behavior of a system Each use-case focuses on one business process Architecture centric Functional (external) view: focuses on the user’s perspective Static (structural) view: focuses on attributes, methods, classes & relationships Dynamic (behavioral) view: focuses on messages between classes and resulting behaviors IS Department 32 Object-Oriented Systems Analysis & Design (cont.) Iterative & incremental Undergoes continuous testing & refinement The analyst understands the system better over time Benefits of OOSAD Break a complex system into smaller, more manageable modules Work on modules individually See the system more realistically—as the users do IS Department 33 The Unified Process A specific methodology that maps out when and how to use the various UML techniques for object-oriented analysis and design A two-dimensional process consisting of phases and workflows Phases are time periods in development Workflows are the tasks that occur in each phase Activities in both phases & workflows will overlap IS Department 34 The Unified Process IS Department 35 Unified Process Phases Inception Do we have the technical capability to build it (technical feasibility)? If we build it, will it provide business value (economic feasibility)? If we build it, will it be used by the organization (organizational feasibility)? Elaboration Heavy focus on analysis & design Other workflows may be included IS Department 36 Unified Process Phases Construction: Focus on programming (implementation) Transition--Focus on testing & deployment IS Department 37 Workflows The workflows describe the tasks or activities that a developer performs to evolve an information system over time. The workflows of the Unified Process are grouped into two broad categories: engineering and supporting. IS Department 38 Engineering Workflows Business modeling Requirements Analysis Design Implementation Testing Deployment IS Department 39 Supporting Workflows Project management Configuration and change management Environment IS Department 40 Extensions to the Unified Process The Unified Process does not include: Staffing Budgeting Contract management Maintenance Operations Support Cross- or inter-project issues IS Department 41 Extensions to the Unified Process (cont.) Add a Production Phase to address issues after the product has been deployed And add two New Workflows: Operations & Support Infrastructure management Modifications to existing workflows: Test workflow Deployment workflow Environment workflow Project Management workflow Configuration & change management workflow IS Department 42 IS Department 43 Enhanced Unified Process IS Department 44 Unified Modeling Language (UML) Provides a common vocabulary of object- oriented terms and diagramming techniques rich enough to model any systems development project from analysis through implementation The current version of UML is Version 2.5 that has 15 diagrams in 2 major groups: Structure diagrams Behavior diagrams IS Department 45 Unified Modeling Language (UML) IS Department 46