Systems Analysis _amp; Design

Document Sample
Systems Analysis _amp; Design Powered By Docstoc
					             CSUN Information Systems


        Systems Analysis & Design
     http://www.csun.edu/~dn58412/IS431/IS431_SP13.htm



                         System
                         Development
                         Process
IS 431: Lecture 2

                                                         1
               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             2
               Information Systems in
               Organization
         STRATEGIC                    EXECUTIVE INFORMATION SYSTEMS




         TACTICAL                  MANAGEMENT INFORMATION SYSTEMS




                                    TRANSACTION PROCESSING SYSTEMS
        OPERATIONAL



A   F    H     P        S      O
C   I    U     R        A      T
C   N    M     O        L      H
O   A    A     D        E      E
U   N    N     U        S      R
N   C          C               S
T   E    R     T
I        E     I
N        S     O
G              N

    VALUE CHAIN
                     IS 431 : Lecture 2                               3
                            The Value Chain
                        SUPPORT ACTIVITIES
                         FIRM INFRASTRUCTURE
                         HUMAN RESOURCES
                         TECHNOLOGY
                         PURCHASING



 INBOUND                            OUTBOUND           MARKETING
                OPERATIONS                                               SERVICE
LOGISTICS                           LOGISTICS           & SALES

                         PRIMARY ACTIVITIES
 Receiving,
   Storing,                               Distribution     Advertising     Repair
 Distributing     Manufacturing         Order Processing    Selling      Maintenance
Raw Materials

                                  IS 431 : Lecture 2                               4
                  The Value Chain
                          VALUE




                    FIRM INFRASTRUCTURE

                  HUMAN RESOURCE MANAGEMENT

                    TECHNOLOGY DEVELOPMENT

                         PROCUREMENT




INBOUND     OPERATIONS   OUTBOUND      MARKETING
LOGISTICS                                          SERVICE
                         LOGISTIC      & SALES
                                       LOGISTIC




                            COST                        MARGIN




                    IS 431 : Lecture 2                           5
                 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                         6
 Emerging Technology in
Business Innovation Cycle




 IS 431 : Lecture 2         7
IS 431 : Lecture 2   8
                  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                     9
                    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                                 10
                           System Development
                           Process and Quality

                CMM Project Statistics for a Project Resulting
                         in 200,000 Lines of Code
Organization’    Project   Project     Number of   Median      Lowest        Highest
s CMM Level     Duration   Person-      Defects    Cost ($     Cost ($        Cost
                (months)   Months       Shipped    millions)   millions)   ($ millions)
     1            30        600            61        5.5         1.8          100+
     2            18.5      143            12        1.3         .96           1.7
     3            15         80            7         .728        .518         .933




                             IS 431 : Lecture 2                                      11
                  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                       12
A System Life Cycle




 IS 431 : Lecture 2   13
              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            14
                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           15
                   A  Meeting Transcript
 System Developer:
  – “I am 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                       16
                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                       17
                 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                        18
                      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                      19
                  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                         20
                  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                     21
                  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                        22
                         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                                       23
                    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                               24
                 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                  25
                  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                        26
                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                   27
                   Where Do Systems
                   Development Projects
                   Come From?
 Planned Projects
   – An information systems strategy plan 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                        28
                 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                         29
                   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                        30
Classic Project Phases




 IS 431 : Lecture 2      31
System Building Blocks




 IS 431 : Lecture 2      32
                 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                  33
               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                   34
               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                  35
                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: 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.
•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                   36
              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                   37
                      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                              38
                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                  39
               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                 40
               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                 41
               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                  42
               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                   43
Systems Development
Process in Practice




 IS 431 : Lecture 2   44
System Development
Documentations




 IS 431 : Lecture 2   45
                     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                               46
         System Analysis &
         Design Approaches

 DEVELOPMENT
  • Modeling
  • Prototyping (RAD)
 IMPLEMENTATION
  • Build (In-house)
  • Buy (COTS)



           IS 431 : Lecture 2   47
Model-Driven
Development




IS 431 : Lecture 2   48
                       Model-Driven
                       Development
Model-driven development – 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                                49
                 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                 50
                  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                        51
Rapid Application
Development




IS 431 : Lecture 2   52
                     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                                53
                 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                          54
                 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                          55
Commerce
Application Package




 IS 431 : Lecture 2   56
                  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                      57
                 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                       58
                 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                      59
Hybrid Strategies




 IS 431 : Lecture 2   60
Hybrid: Multiple
Implementation




 IS 431 : Lecture 2   61
Hybrid: Staged
Implementation




 IS 431 : Lecture 2   62
System Maintenance




 IS 431 : Lecture 2   63
               Automated Tools and
               Technology
 Computer-aided systems engineering (CASE)
 Application development environments (ADEs)
 Process and project managers




                 IS 431 : Lecture 2             64
                   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                          65
CASE Tool Architecture




 IS 431 : Lecture 2      66
                       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                67
                  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                      68

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:4
posted:4/28/2013
language:Latin
pages:68