Systems analysis design
1 / 68

- PowerPoint PPT Presentation

  • Updated On :

CSUN Information Systems. Systems Analysis & Design. System Development Process. IS 431: Lecture 2. System Development Process. Value Chain and Innovation Cycle Principles of systems development.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about '' - tal

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Systems analysis design l.jpg

CSUN Information Systems

Systems Analysis & Design

System Development Process

IS 431: Lecture 2

System development process l.jpg
System Development Process

  • Value Chain and Innovation Cycle

  • Principles of systems development.

  • PIECES framework for categorizing problems, opportunities, and directives.

  • Systems development phases: purpose, inputs, and outputs.

  • Alternative “routes” through the basic phases of system development.

  • Computer-aided systems engineering (CASE) and application development environments (ADEs)

IS 431 : Lecture 2

Slide3 l.jpg

Information Systems in Organization


















IS 431 : Lecture 2

The value chain l.jpg
The Value Chain


















Raw Materials



Order Processing





IS 431 : Lecture 2

The value chain5 l.jpg
The Value Chain

















IS 431 : Lecture 2

Value added activities l.jpg
Value-Added Activities

  • Customer-Value-Added Activity (maximize)

    • a business process generating a value (utility) that a customer is willing to pay for

  • Business-Value-Added Activity (minimize)

    • a business process that is essential to managing an organization (cost)

  • Non-Value-Added Activity (eliminate)

    • customer will not pay; business value will not be increased (waste)

  • Goals of a business system: effective (do right thing), efficient (do thing right), competitive (do thing differently).

IS 431 : Lecture 2

Emerging technology in business innovation cycle l.jpg
Emerging Technology in Business Innovation Cycle

IS 431 : Lecture 2

System development process9 l.jpg
System Development Process

  • 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

  • CMM Requirement

  • A consistent process for system development assures

    • Efficiencies to allow management to shift resources between projects (best practices/ thorough procedures)

    • Consistent documentation to reduce lifetime costs to maintain the systems (by other developers/teams)

    • Consistent quality across projects

IS 431 : Lecture 2

Cmm process management model l.jpg
CMM Process Management Model

Capability Maturity Model (CMM) – a standardized framework for assessing the maturity level of an organization’s information system development and management processes and products. It consists of five levels of maturity:

  • Level 1—Initial: System development projects follow no prescribed process.

  • Level 2—Repeatable: Project management processes and practices are established to track project costs, schedules, and functionality.

  • Level 3—Defined: A standard system development process (a “methodology”) is purchased or developed. All projects use a version of this process to develop and maintain information systems and software.

  • Level 4—Managed: Measurable goals for quality and productivity are established.

  • Level 5—Optimizing: The standardized system development process is continuously monitored and improved based on measures and data analysis established in Level 4.

IS 431 : Lecture 2

Life cycle vs methodology l.jpg
Life Cycle vs.Methodology

  • System life cycle – the factoring of the lifetime of an information system into two stages, (1) systems development and (2) systems operation and maintenance.

  • System development methodology – a standardized development process that defines a set of activities, methods, best practices, deliverables, and automated tools that system developers and project managers are to use to develop and continuously improve information systems and software.

IS 431 : Lecture 2

A system life cycle l.jpg
A System Life Cycle

IS 431 : Lecture 2

System development methodologies l.jpg
System Development Methodologies

  • Architected Rapid Application Development (Architected RAD)

  • Dynamic Systems Development Methodology (DSDM)

  • Joint Application Development (JAD)

  • Information Engineering (IE)

  • Rapid Application Development (RAD)

  • Rational Unified Process (RUP)

  • Structured Analysis and Design

  • eXtreme Programming (XP)

IS 431 : Lecture 2

Principles of system development l.jpg
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 431 : Lecture 2

A meeting transcript l.jpg
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 431 : Lecture 2

Principles of system development17 l.jpg
Principles of System Development …

  • 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 etc, etc [fiddles playing softly in the background…]”

IS 431 : Lecture 2

Principles of system development18 l.jpg
Principles of System Development …

  • 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

  • Solve a WRONG problem with a WRONG solution !!!

IS 431 : Lecture 2

Principles of system development19 l.jpg
Principles of System Development …

  • 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)

IS 431 : Lecture 2

Principles of system development20 l.jpg
Principles of System Development …

  • 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.

IS 431 : Lecture 2

Principles of system development21 l.jpg
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

IS 431 : Lecture 2

Principles of system development22 l.jpg
Principles of System Development …

  • 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.

IS 431 : Lecture 2

Principles of system development23 l.jpg
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

        *In fact, there is a saying “ If you have two alternatives to solve a problem, the third one is the best ” (See Murphy’s Laws)

IS 431 : Lecture 2

Principles of system development24 l.jpg
Principles of System Development …

  • 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 expanding (ANALYST)

      • Reduce the scope if budget/schedule shrinking (ANALYST)

IS 431 : Lecture 2

Principles of system development25 l.jpg
Principles of System Development …

  • 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

IS 431 : Lecture 2

Principles of system development26 l.jpg
Principles of System Development …

  • Principle 10: Design Systems for Growth and Change

    • The entropy of a system

    • Changes of technology, user requirements

    • Flexibility and adaptability should be built into the system

IS 431 : Lecture 2

Where do systems development projects come from l.jpg
Where Do Systems Development Projects Come 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 431 : Lecture 2

Where do systems development projects come from28 l.jpg
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 431 : Lecture 2

Where do systems development projects come from29 l.jpg
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 431 : Lecture 2

Pieces framework for systems improvement l.jpg
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 431 : Lecture 2

Classic project phases l.jpg
Classic Project Phases

IS 431 : Lecture 2

Slide32 l.jpg

System Building Blocks

IS 431 : Lecture 2

1 scope definition l.jpg
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 431 : Lecture 2

2 problem analysis l.jpg
2. Problem Analysis

  • 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

IS 431 : Lecture 2

3 requirement analysis l.jpg
3. Requirement Analysis

  • 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 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 431 : Lecture 2

4 logical design l.jpg
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 431 : Lecture 2

5 decision analysis l.jpg
5. Decision Analysis

  • 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

IS 431 : Lecture 2

Decision analysis preview l.jpg
Decision Analysis Preview

  • 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)

IS 431 : Lecture 2

6 physical design l.jpg
6. Physical Design

  • 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 (blueprints)

  • Feasibility check: Continue/ Reduce or expanse the scope with budget and schedule modification

IS 431 : Lecture 2

7 construction phase l.jpg
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 431 : Lecture 2

8 implementation phase l.jpg
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 431 : Lecture 2

Operation and support l.jpg
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 431 : Lecture 2

Summary systems development process l.jpg
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 431 : Lecture 2

Cross life cycle activities l.jpg
Cross Life-Cycle Activities

Cross life-cycle activity – any activity that overlaps many or all phases of the systems development process.

  • Fact-finding

    • 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

IS 431 : Lecture 2

System analysis design approaches l.jpg
System Analysis & Design Approaches


    • Modeling

    • Prototyping (RAD)


    • Build (In-house)

    • Buy (COTS)

IS 431 : Lecture 2

Model driven development l.jpg
Model-Driven Development

IS 431 : Lecture 2

Model driven development49 l.jpg
Model-Driven Development

  • Model-drivendevelopment – a system development strategy that emphasizes the drawing of system models to help visualize and analyze problems, define business requirements, and design information systems.

    • Process Modeling – a process-centered technique popularized by the structured analysis and design methodology used models of business process requirements to derive effective software designs for a system.

    • Data Modeling – a data-centered technique to model business data requirements and design appropriate database systems.

    • Object Modeling – a technique to merge the data and process concerns into singular constructs called objects. Object models are diagrams that document a system in terms of its objects and their interactions.

IS 431 : Lecture 2

Model driven development50 l.jpg
Model-Driven Development …

  • Advantages:

    • Planning ahead

    • Extensive modeling current system and requirement analysis

    • Analyze many alternative technical solutions

    • Suitable for well understood systems

IS 431 : Lecture 2

Model driven development51 l.jpg
Model-Driven Development …

  • Disadvantages:

    • Long duration

    • Passive participation of user as they don’t see the product

    • Requirements in each phase should be fully addressed: impractical and/or inflexible

IS 431 : Lecture 2

Rapid application development53 l.jpg
Rapid Application Development

  • Rapid application development (RAD) techniques emphasize extensive user involvement in the rapid and evolutionary construction of working prototypes of a system to accelerate the system development process.RAD is based on building prototypes that evolve into finished systems (often using time boxing)

    • A prototype is a smaller-scale, representative or working model of the users’ requirements or a proposed design for an information system.

    • A time box is a non-extendable period of time, usually 60-120 days, by which a candidate system must be placed into operation. Improvements will be released in later versions

IS 431 : Lecture 2

Rapid application development54 l.jpg
Rapid Application Development …

  • Advantages:

    • Handle uncertain or imprecise user requirements

    • Active user participation in building physical product: increase enthusiasm, support

    • Early detection of errors and omissions: with testing and modifying prototype

    • Reduce risk with iterative prototyping

IS 431 : Lecture 2

Rapid application development55 l.jpg
Rapid Application Development …

  • Disadvantages:

    • Increase lifetime costs to operate, support, and maintain the system (constantly doing and fixing)

    • Short problem analysis may result in solving wrong problems

    • Discourage an analyst from considering other technical alternatives than the one being used in prototyping

IS 431 : Lecture 2

Commerce application package l.jpg
Commerce Application Package

IS 431 : Lecture 2

Commerce application package57 l.jpg
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 431 : Lecture 2

Commercial off the shelf software l.jpg
Commercial Off-the-Shelf Software …

  • Advantages

    • Fast implementation of new system (many functions are similar across businesses, no need to build them from scratch.)

    • No need for expertise and staff for in-house development

    • Low development costs (but expensive to customize and implement !!!)

    • Vendors are responsible for software improvements and error corrections

IS 431 : Lecture 2

Commercial off the shelf software59 l.jpg
Commercial Off-the-Shelf Software …

  • Disadvantages

    • Dependent on the vendors

    • Future upgrade/customization is expensive

    • A COTS rarely reflects ideal solution developed in-house

    • Changing current business processes to fit the COTS

IS 431 : Lecture 2

Hybrid strategies l.jpg
Hybrid Strategies

IS 431 : Lecture 2

Hybrid staged implementation l.jpg
Hybrid: Staged Implementation

IS 431 : Lecture 2

System maintenance l.jpg
System Maintenance

IS 431 : Lecture 2

Automated tools and technology l.jpg
Automated Tools and Technology

  • Computer-aided systems engineering (CASE)

  • Application development environments (ADEs)

  • Process and project managers

IS 431 : Lecture 2

Computer assisted software engineering l.jpg
Computer-Assisted Software Engineering

Computer-aided systems engineering (CASE) – the use of automated software tools that support the drawing and analysis of system models and associated specifications. Some CASE tools also provide prototyping and code generation capabilities.

  • CASE repository – a system developers’ database where developers can store system models, detailed descriptions and specifications, and other products of system development. Synonyms include dictionary and encyclopedia.

  • Forward engineering – a CASE tool capability that can generate initial software or database code directly from system.

  • Reverse engineering – a CASE tool capability that can generate initial system models from software or database code.

IS 431 : Lecture 2

Case tool architecture l.jpg
CASE Tool Architecture

IS 431 : Lecture 2

Application development environments l.jpg
Application Development Environments

Application development environments (ADEs) – an integrated software development tool that provides all the facilities necessary to develop new application software with maximum speed and quality. A common synonym is integrated development environment (IDE)

  • ADE facilities may include:

    • Programming languages or interpreters

    • Interface construction tools

    • Middleware

    • Testing tools

    • Version control tools

    • Help authoring tools

    • Repository links

IS 431 : Lecture 2

Process and project managers l.jpg
Process and Project Managers

  • Process manager application – an automated tool that helps document and manage a methodology and routes, its deliverables, and quality management standards. An emerging synonym is methodware (e.g., Visio, Visible Analyst, Rational Rose etc.).

  • Project manager application – an automated tool to help plan system development activities (preferably using the approved methodology), estimate and assign resources (including people and costs), schedule activities and resources, monitor progress against schedule and budget, control and modify schedule and resources, and report project progress (e.g., MS Project etc.).

IS 431 : Lecture 2