ITM305 â Chapter 1 Introduction to Systems Analysis and Design ...
ITM305 – Chapter 1 Introduction to Systems Analysis and Design Introduction
System development life cycle (SDLC): the process of understanding how an information system (IS) can support business needs by designing a system, building it, and delivering it to users
Key person in SDLC is the systems analyst o Analyzes business situation, identifies opportunities for improvements, and design an IS to implement them o Primary objective is to create value for the organization (increasing profits)
The Systems Development Life Cycle
Building an IS is similar to building a house o Basic idea o Idea is transformed into simple drawing and refined o A set of blueprints is designed that has more detail info o Finally, it is built following the blueprints (some things are also subject to change)
SDLC has four fundamental phases (each has steps, techniques, and deliverables): o Planning o Analysis o Design o Implementation
Planning
Planning phase is the fundamental process of understanding why an IS should be built and determining how the project team will build it 1. Project initiation – the system’s business value is identified:
System request – how will it lower costs or increase revenues (from marketing department, accounting department)?
The IS dept. works together with project sponsor (who made the request) to conduct a feasibility analysis Feasibility analysis examines: Idea’s technical feasibility (can we build it?) Economic feasibility (will it provide business value?) Organizational feasibility (if we build it, will it be used?)
The system request and feasibility are presented to IS approval committee
2. Once approved, it enters project management
The project manager creates a workplan, staffs the project, and puts techniques in place
Analysis
Analysis phase answers the questions of who will use the system, what the system will do and where and when it will be used o Investigates any current system(s), identifies opportunities for improvement, and develops a concept for the new system 1. Analysis strategy is developed to guide the project team’s effort
As-is system – an analysis of the current system
To-be system – problems and ways to design a new system
2. Requirements gathering (ex. interviews or questionnaires)
The system concept is then used as basis to develop a set of business analysis models (how the business will operate if the new system is developed)
The analyses, system concept, and models are combined into a document called system proposal (present to project sponsor and other key decision makers)
Design
Design place decides how the system will operate (hardware, software, network infrastructure, user interface, forms and reports, program, databases, etc) 1. Design strategy first developed (whether the system will be developed by company’s own programmers, outsourced to another firm, or buy an existing software package) 2. Architecture design – describes the hardware, software, and network infrastructure to be used Interface design – how users will move through the system (menus, on-screen buttons, etc) and the forms and reports that the system will use 3. Database and file specifications are developed – define exactly what data will be stored and where 4. The analyst team develops the program design – defines programs that need to be written and exactly what each program will do
This collection of deliverables is the system specification handed to the programming team
Implementation
Implementation phase, the system is actually built (or purchased) – most longest and expensive part of development process 1. System construction is the first step – system is built and tested (more attention to testing than writing the program) 2. Installation – process in which old system is turned off and new one turned on
One of most important part of conversion is development of training plan (to teach others the new system and help manage the changes)
3. Analyst team establishes a support plan – includes formal/informal postimplementation review as well as systematic way for identify changes Systems Development Methodologies
A methodology is a formalized approach to implementing SDLC (i.e. list of steps and deliverables)
A process-centered methodology emphasizes process models as the core of the system concept (ex. assemble sandwich ingredients)
A data-centered methodologies emphasize data models as the core of the system concept (ex. defining contents of storage areas; refrigerator)
Object-oriented methodologies attempt to balance the focus b/w process and data by incorporating both in 1 model
Structured Design
The first category of systems development methodologies is called structured design
Waterfall o The original structured design methodology
Parallel Development o Attempts to address the problem of long delays b/w the analysis phase
Rapid Application Development (RAD)
Phased development
Prototyping
Throwaway prototyping
Agile Development
Extreme programming (XP)
SCRUM
Selecting the Appropriate Development Methodology
Typical Systems Analyst Roles and Skills
Agents of change o Identify ways to improve the organization o Motivate & train others
Skills needed: o Technical: must understand technology o Business: must know business processes o Analytical: must be able to solve problems o Communications: technical & non-technical audiences o Interpersonal: leadership & management o Ethics: deal fairly and protect confidential info
Basic Characteristics of Object-Oriented Systems
Attempts to balance data and process
Utilizes the Unified Modeling Language (UML) and the Unified Process
Characteristics of OOSAD: o Use-case Driven o Architecture Centric o Iterative and Incremental
Classes & Objects o Object (instance): instantiation of a class o Attributes: information that describes a class o State: describes its values and relationships at a point in time
Methods & Messages o Methods: behaviour of a class o Messages: info sent to an object to trigger a method (procedure call)
Encapsulation & information hiding o Encapsulation: combination of process & data o Information hiding: functionality is hidden
Inheritance o General classes are created (superclasses) o Subclasses can inherit data and methods from superclass
Polymorphism & dynamic binding o Polymorphism: same message can have different meanings o Dynamic binding: type of object is not determined until run-time o Contrast with static binding
Object-oriented Systems Analysis and Design (OOSAD)
Use-case driven o Use-cases define the behaviour of s system o Each use-case focuses on one business process
Architecture centric o Functional (external) view: focuses on the user’s perspective o Static (structural) view: focuses on attributes, methods, classes & relationships o Dynamic (behavioural) view: focuses on messages b/w class and resulting behaviours
Iterative & incremental o Undergoes continuous testing & refinement o The analyst understands the system better over time
Benefits of OOSAD o Break a complex system into smaller, more manageable modules o Work on modules individually o See the system more realistically – as users do
The Unified Process
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 o Phases are time periods in development o Workflows are the tasks that occur in each phase o Activities in both phases & workflows
Inception
o Feasibility analyses performed o Workflows vary but focus is on business modeling & requirements gathering
Elaboration o Heavy focus on analysis & design o Other workflows may be included
Construction: focus on programming (implementation)
Transition: focus on testing & deployment
Workflows
Engineering workflows o Business modeling o Requirements o Analysis o Design o Implementation o Testing o Deployment
Supporting Workflows o Project management o Configuration and change management o Environment o Operations and support* (part of enhanced unified process) o Infrastructure management* (part of enhanced unified process)
Extensions to the Unified Process o The Unified Process doesn’t include:
Staffing
Budgeting
Contract management
Maintenance
Operations
Support
Cross- or inter-project issues
Add a Production Phase to address issues after the product has been deployed
Net Workflows: o Operations & Support o Infrastructure management
Modifications to existing workflows: o Test workflow o Deployment workflow o Environment workflow o Project Management workflow o Configuration & change management workflow
Unified Modeling Language o Provides a common vocabulary of object-oriented terms and diagramming techniques rich enough to model any systems development project from analysis through implementation o Version 2.0 has 14 diagrams in 2 major groups: Structure & Behaviour diagrams
UML Structure Diagrams: represent the data and static relationship in an IS o Class o Object o Package o Deployment o Component o Composite structure
UML Behaviour Diagrams o Depict the dynamic relationships among the instances or objects that represent the business info system
Activity
Sequence
Communication
Interaction overview
Timing
Behaviour state machine
Protocol state machine
Use-case diagrams
System development life cycle (SDLC): the process of understanding how an information system (IS) can support business needs by designing a system, building it, and delivering it to users
Key person in SDLC is the systems analyst o Analyzes business situation, identifies opportunities for improvements, and design an IS to implement them o Primary objective is to create value for the organization (increasing profits)
The Systems Development Life Cycle
Building an IS is similar to building a house o Basic idea o Idea is transformed into simple drawing and refined o A set of blueprints is designed that has more detail info o Finally, it is built following the blueprints (some things are also subject to change)
SDLC has four fundamental phases (each has steps, techniques, and deliverables): o Planning o Analysis o Design o Implementation
Planning
Planning phase is the fundamental process of understanding why an IS should be built and determining how the project team will build it 1. Project initiation – the system’s business value is identified:
System request – how will it lower costs or increase revenues (from marketing department, accounting department)?
The IS dept. works together with project sponsor (who made the request) to conduct a feasibility analysis Feasibility analysis examines: Idea’s technical feasibility (can we build it?) Economic feasibility (will it provide business value?) Organizational feasibility (if we build it, will it be used?)
The system request and feasibility are presented to IS approval committee
2. Once approved, it enters project management
The project manager creates a workplan, staffs the project, and puts techniques in place
Analysis
Analysis phase answers the questions of who will use the system, what the system will do and where and when it will be used o Investigates any current system(s), identifies opportunities for improvement, and develops a concept for the new system 1. Analysis strategy is developed to guide the project team’s effort
As-is system – an analysis of the current system
To-be system – problems and ways to design a new system
2. Requirements gathering (ex. interviews or questionnaires)
The system concept is then used as basis to develop a set of business analysis models (how the business will operate if the new system is developed)
The analyses, system concept, and models are combined into a document called system proposal (present to project sponsor and other key decision makers)
Design
Design place decides how the system will operate (hardware, software, network infrastructure, user interface, forms and reports, program, databases, etc) 1. Design strategy first developed (whether the system will be developed by company’s own programmers, outsourced to another firm, or buy an existing software package) 2. Architecture design – describes the hardware, software, and network infrastructure to be used Interface design – how users will move through the system (menus, on-screen buttons, etc) and the forms and reports that the system will use 3. Database and file specifications are developed – define exactly what data will be stored and where 4. The analyst team develops the program design – defines programs that need to be written and exactly what each program will do
This collection of deliverables is the system specification handed to the programming team
Implementation
Implementation phase, the system is actually built (or purchased) – most longest and expensive part of development process 1. System construction is the first step – system is built and tested (more attention to testing than writing the program) 2. Installation – process in which old system is turned off and new one turned on
One of most important part of conversion is development of training plan (to teach others the new system and help manage the changes)
3. Analyst team establishes a support plan – includes formal/informal postimplementation review as well as systematic way for identify changes Systems Development Methodologies
A methodology is a formalized approach to implementing SDLC (i.e. list of steps and deliverables)
A process-centered methodology emphasizes process models as the core of the system concept (ex. assemble sandwich ingredients)
A data-centered methodologies emphasize data models as the core of the system concept (ex. defining contents of storage areas; refrigerator)
Object-oriented methodologies attempt to balance the focus b/w process and data by incorporating both in 1 model
Structured Design
The first category of systems development methodologies is called structured design
Waterfall o The original structured design methodology
Parallel Development o Attempts to address the problem of long delays b/w the analysis phase
Rapid Application Development (RAD)
Phased development
Prototyping
Throwaway prototyping
Agile Development
Extreme programming (XP)
SCRUM
Selecting the Appropriate Development Methodology
Typical Systems Analyst Roles and Skills
Agents of change o Identify ways to improve the organization o Motivate & train others
Skills needed: o Technical: must understand technology o Business: must know business processes o Analytical: must be able to solve problems o Communications: technical & non-technical audiences o Interpersonal: leadership & management o Ethics: deal fairly and protect confidential info
Basic Characteristics of Object-Oriented Systems
Attempts to balance data and process
Utilizes the Unified Modeling Language (UML) and the Unified Process
Characteristics of OOSAD: o Use-case Driven o Architecture Centric o Iterative and Incremental
Classes & Objects o Object (instance): instantiation of a class o Attributes: information that describes a class o State: describes its values and relationships at a point in time
Methods & Messages o Methods: behaviour of a class o Messages: info sent to an object to trigger a method (procedure call)
Encapsulation & information hiding o Encapsulation: combination of process & data o Information hiding: functionality is hidden
Inheritance o General classes are created (superclasses) o Subclasses can inherit data and methods from superclass
Polymorphism & dynamic binding o Polymorphism: same message can have different meanings o Dynamic binding: type of object is not determined until run-time o Contrast with static binding
Object-oriented Systems Analysis and Design (OOSAD)
Use-case driven o Use-cases define the behaviour of s system o Each use-case focuses on one business process
Architecture centric o Functional (external) view: focuses on the user’s perspective o Static (structural) view: focuses on attributes, methods, classes & relationships o Dynamic (behavioural) view: focuses on messages b/w class and resulting behaviours
Iterative & incremental o Undergoes continuous testing & refinement o The analyst understands the system better over time
Benefits of OOSAD o Break a complex system into smaller, more manageable modules o Work on modules individually o See the system more realistically – as users do
The Unified Process
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 o Phases are time periods in development o Workflows are the tasks that occur in each phase o Activities in both phases & workflows
Inception
o Feasibility analyses performed o Workflows vary but focus is on business modeling & requirements gathering
Elaboration o Heavy focus on analysis & design o Other workflows may be included
Construction: focus on programming (implementation)
Transition: focus on testing & deployment
Workflows
Engineering workflows o Business modeling o Requirements o Analysis o Design o Implementation o Testing o Deployment
Supporting Workflows o Project management o Configuration and change management o Environment o Operations and support* (part of enhanced unified process) o Infrastructure management* (part of enhanced unified process)
Extensions to the Unified Process o The Unified Process doesn’t include:
Staffing
Budgeting
Contract management
Maintenance
Operations
Support
Cross- or inter-project issues
Add a Production Phase to address issues after the product has been deployed
Net Workflows: o Operations & Support o Infrastructure management
Modifications to existing workflows: o Test workflow o Deployment workflow o Environment workflow o Project Management workflow o Configuration & change management workflow
Unified Modeling Language o Provides a common vocabulary of object-oriented terms and diagramming techniques rich enough to model any systems development project from analysis through implementation o Version 2.0 has 14 diagrams in 2 major groups: Structure & Behaviour diagrams
UML Structure Diagrams: represent the data and static relationship in an IS o Class o Object o Package o Deployment o Component o Composite structure
UML Behaviour Diagrams o Depict the dynamic relationships among the instances or objects that represent the business info system
Activity
Sequence
Communication
Interaction overview
Timing
Behaviour state machine
Protocol state machine
Use-case diagrams
