S1: Meeting 9
Copyright: S. Shekhar, C. S. Dept., University of Minnesota, Minneapolis, MN 55455. ,,.(home)
S2: 13. Integration Phase Overview
  • Life Cycle Context
    • What is percentage effort ? (Schach, Figure 1.2)
    • What is the relative bug-fixing cost? (Schach, Figure 1.5)
  • What is Integration Phase?
    • a later phase of the software life cycle
    • Often overlaps with implementation phase
    • Testing is an important part of integration
    • Recall waterfall model, Fig. 3.2
  • What is integration?
    • Connecting chunks together
    • Ex.: Linking (e.g. in C/C++)
    • Module interconnection diagram (Fig. 13.1)
Copyright: S. Shekhar, C. S. Dept., University of Minnesota, Minneapolis, MN 55455. ,,.(home)
S3: 13.1 Interleaving Implementation and Integration
  • Non-interleaved :
    • Write and test each module, then link them all togther
  • Interleaved:
    • Implement a "leaf" module, test it,
    • Implement a connected module, test both together
    • Repeat previous step to completion
  • Possible advantages of Interleaving
    • Fault isolation : locates bugs
    • Save overhead of stubs and drivers
    • Q? How many stubs & drivers for Fig. 13.1?
  • Types of Interleaving
    • Top down (See Fig. 13.1 )
    • Bottom up (Fig. 13.1)
    • Sandwich (Fig. 13.2 )
    • Q? Order module in Fig. 13.1 top-down
    • Q? Order module in Fig. 13.1 bottom up
Copyright: S. Shekhar, C. S. Dept., University of Minnesota, Minneapolis, MN 55455. ,,.(home)
S4: 13.1 Interleaving Implementation and Integration
  • Issues for Comparing types of interleavings
    • Q? When are global defects affecting detected?
      • Late detection = > more modules to revise to fix it!
    • Q? Which modules are tested more ?
      • More complex ones, top ones, bottom ones?
    • Top down :
    • Global design defects detected early
    • High modules are tested more than low modules
  • Bottom up :
    • Lower modules are tested more than high ones
    • High-level design defects appear late . . .
  • Sandwich :
    • Finds high-level design defects early
    • Lower modules are tested adequately
Copyright: S. Shekhar, C. S. Dept., University of Minnesota, Minneapolis, MN 55455. ,,.(home)
S5: 13.2-13.5 Testing during Integration
  • Integration Test: if module work together
  • Product testing - before client sees it
    • approximate acceptance criteria
    • Robustness testing (can system break?)
    • Stress testing (behaviour under peak load)
    • Volume testing for non-functional constraints
  • Acceptance testing - client must participate
    • Client determines if product satisfies the specs
    • Performed on actual data not test data
    • Sometimes new product is run in parallel with old one
    • A milestone to end Development
    • Developers
    • Software Quality Assurance
    • Clients
Copyright: S. Shekhar, C. S. Dept., University of Minnesota, Minneapolis, MN 55455. ,,.(home)
S6: 13.6-13.14 CASE Tools and Environments, Metrics
  • Environments
    • Language centered: Interlisp, Ada
    • Structure oriented:
    • Toolkit: Unix
    • Integrated: Process based - Rational ROSE;
      • Common data format - Unix / Microsoft
    • Business Application: 4GL + Code generators
    • Public/Open Infrastructure: CORBA, COM
  • Metrics for Integration Phase
    • How long to continue testing without a failure?
    • Approach by Brettscneider assuming
      • Pr[failure] decreases exponentially as testing progresses (?)
      • page 456, f( target#faults, detected#failures, #testHours)
    • Testing Metrics
    • Number of testcase revealing faults
    • Fault statistics by fault type, modules, etc.
Copyright: S. Shekhar, C. S. Dept., University of Minnesota, Minneapolis, MN 55455. ,,.(home)
S7: Exercises
  • Apply section 13.1.4 (pp. 443) to MSG Case Study
    • Determine following order of module implementation/integration
      • Top Down
      • Bottom Up
      • Sandwich
    • Q? Build base classes or derived classes first?
    • Q? How do we order implementation of Static methods?
  • Q. Match following testing objective to life-cycle phases:
    • Are descriptions complete? Unambiguous?
    • Do modules work?
    • Do modules work together?
    • Does design match specs? Are there mistakes?
    • Has recent change introduced new faults?
    • Is this really what the client needs?
    • Will the plan (budget, schedule, staffing etc.) work?
Copyright: S. Shekhar, C. S. Dept., University of Minnesota, Minneapolis, MN 55455. ,,.(home)
S8: 14.1-14.3 Motivation, Tasks, Case Study
  • Life-Cycle Perspective (Fig. 3.2)
    • Last major stage : everything after acceptance test!
    • Relative importance in life-cycle (Schach, Figure 1.5)
    • What fraction of the life-cycle is maintenance?
    • Answer in Fig. 1.2
  • What is Maintenance?
    • Any changes after client has accepted product (p. 465)
    • Any changes to documentation, manuals, or other component
      • of the product are . . . maintenance (p. 465)
    • Types of Maintenance
    • Corrective: Fix bugs that were not caught previously
    • Perfective: Improve (e.g. new features) the software
    • Adaptive; Port software to another environment
      • another computer, organization, tax year...
    • Other kinds of Maintenance:
      • Ex. remove a capability;
      • set up initialization (e.g. autoexec.bat )
Copyright: S. Shekhar, C. S. Dept., University of Minnesota, Minneapolis, MN 55455. ,,.(home)
S9: 14.1-14.3 Motivation, Tasks, Case Study
  • Exercises
    • Q? Which class contains Y2K projects?
    • Q? Estimate percentage for each type of maintenance
      • For the answer, see Fig. 14.1
    • Maintenance Programming (14.2)
    • " ... most difficult of all aspects of software production"
    • ". . . most challenging phase of software production -
      • and frequently the most thankless"
    • Maintenance Programmers
    • "...need every technical skill that a software professional could have." SubItem%" needs . . . far above average debugging skills . . ."
    • "But many assign the task of maintenance to beginners..."
  • Solution: "Managers must assign maintenance . .
    • to their best programmers . . .
    • and pay them accordingly"
    • Q? Is it happening for Y2K?
Copyright: S. Shekhar, C. S. Dept., University of Minnesota, Minneapolis, MN 55455. ,,.(home)
S10: 14.1-14.3 Motivation, Tasks, Case Study
  • Perfective Maintenance & Extensibility
    • Extensibility = ease of perfective maintenance
    • Ex.: defining sizes in a graphics program
      • as fractions of screen height instead of # of pixels
    • Ex.: should a spreadsheet be made easily extensible
      • to handle double precision numbers?
    • Case Study (ref. sec. 14.3)
      A consultant was hired to computerize a nation's fruit management
      "Temperate Fruit Committee"
      The nation has 7 types of temperate fruit
      consultant was ordered not to spend time and expense on extensibility
      A year after, the maintainer was asked to add in Kiwi fruit
      The maintainer was able to add Kiwi fruit easily
      later, the maintainer was told to add in 26 non-temperate fruites
      maintainer said this would require rewriting the whole system
      He was told, since it was so easy to add Kiwi fruit,
      just do the same thing 26 more times
      original consultant might never even find out about this unless
      he reads our text!
      What lessons might we learn from this?
Copyright: S. Shekhar, C. S. Dept., University of Minnesota, Minneapolis, MN 55455. ,,.(home)
S11: 14.4 - 14.6 Issues: Management, OO, Skills

Copyright: S. Shekhar, C. S. Dept., University of Minnesota, Minneapolis, MN 55455. ,,.(home)
S12: 14.7 Reverse Engineering
  • Repetitive Maintenance
    • "If it ain't broke don't fix it"
    • fixing something can break something else
      • when you least expect it
    • Fix or Rebuild
    • The more something is fixed the harder it is to fix next time
    • (Analogy: metal gets brittle the more you deform it)
    • Eventually, it can get easier to rewrite than to fix
  • Reverse Engineering may be needed for rebuild
    • If documentation is missing, incomplete, out-of-date
    • Derive design, specification from Code!
    • e.g. Get Call graph , def-use graph, etc.
      • Derive USES relationship
      • Define modules w/ min-cut partitioning
    • e.g. Study input, output, menus to derive functionality (DFD)
    • Requires educated guessin and verification!
    • Important part of Y2K problem
Copyright: S. Shekhar, C. S. Dept., University of Minnesota, Minneapolis, MN 55455. ,,.(home)
S13: 14.8-14.10 Testing, CASE Tools, Metrics
  • Testing During Maintenance
    • Concern: Unwitting side-effects of maintenance
    • Regression testing - Test changed product against previous
      • test cases to ensure that new faults are not introduced
    • Needs storage of testcases from earlier phases
      • in computer readable form,
    • Changes in specs = > changes in regression test-suites
  • Maintenance Phase Metrics = those from
    • specification, design, implementation, integration, testing
    • Ex. Complexity metrics (12.16, pp. 413)
    • Fault statistics from bug-report
      • Classified by severity and fault type
    • MSG Case Study :
    • Q? Locate modules that need to be fixed for Y2K compliance?
    • Q? Locate modules needing change to add a Graphical
      • User Interface to this software?
    • Q? Match above exercises with types of maintenance.
Copyright: S. Shekhar, C. S. Dept., University of Minnesota, Minneapolis, MN 55455. ,,.(home)