Chapter 3
Upcoming SlideShare
Loading in...5
×
 

Chapter 3

on

  • 682 views

 

Statistics

Views

Total Views
682
Views on SlideShare
682
Embed Views
0

Actions

Likes
0
Downloads
8
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Chapter 3 Chapter 3 Presentation Transcript

  • LIFECYCLE TESTING EMBEDDED SOFTWARE: MULTIPLE V-Model (3)
    • PART II INTRODUCTION
      • Process of developing and testing embedded software
      • The lifecycle structures: the phases, activities within each, and the order
      • The Multiple-V Model:
        • Which test process issues need to be addressed at each stage of development: first a design model (simulator), then build a prototype (via a series of iterations/refinements), and test final product
  • LIFECYCLE TESTING EMBEDDED SOFTWARE: MULTIPLE V-Model (3)
    • 3.0 INTRO
      • The model: a simulated version of the embedded software on a conventional PC (e.g., using Rational Rose UML or Matlab) – tested
      • The prototype: code generation from corrected model is then ported into a prototype (experimental hardware or environment for the embedded software)
      • The final product: code is refined as experimental hardware is systematically/incrementally replaced by actual hardware, and mass produced
      • A V-Model: a developmental model, which takes into account different physical versions of the same system (the model, the prototype, and the product)
      • The Multiple-V Model: Where each physical version is tested completely, using the full testing cycle or process ( except where specific functionalities can’t be tested until later stages ), some versions requiring specific techniques or environments
  • LIFECYCLE TESTING EMBEDDED SOFTWARE: MULTIPLE V-Model (3)
  • LIFECYCLE TESTING EMBEDDED SOFTWARE: MULTIPLE V-Model (3)
    • Iterative and Parallel Development
      • The Multiple-V Model has three stages: design/model, build/prototype, test/product
      • The middle ‘V’, is iterative (systematic refinements), and may use such environments as Rationale Unified Process, eXtreme Programming (XP)
      • Each stages requires: hardware, software experts (working in parallel), project managers, unit/integration/regression testers (iterating with the hardware/software experts as experimental hardware is gradually replaced by the target hardware
  • LIFECYCLE TESTING EMBEDDED SOFTWARE: MULTIPLE V-Model (3)
      • Iterative and Parallel Development
        • The ES requires initial system decomposition for parallel design, development, etc. and stepwise integration
        • The multiple-V model is applied to each component, and during the integration at each stage – an evolutionary process
        • The process becomes tailored toward each unique ES
        • What are the activities within each stage of the Multiple-V Model, and what issues need to be tested?
  • LIFECYCLE TESTING EMBEDDED SOFTWARE: MULTIPLE V-Model (3)
    • What activities and issues requires a mapping into the multiple V’s:
    • Focus: What activity? When can it be done? Against what issue(s)? Which stage?
    • Activities vs Issues – a structured approach to embedded software testing:
      • A. Test techniques
      • B. Test levels and types
      • C. Other Test issues
      • Map issues classified under A, B, and C onto one or more stages of the V-Model
  • LIFECYCLE TESTING EMBEDDED SOFTWARE: MULTIPLE V-Model (3)
  • LIFECYCLE TESTING EMBEDDED SOFTWARE: MULTIPLE V-Model (3)
  • LIFECYCLE TESTING EMBEDDED SOFTWARE: MULTIPLE V-Model (3)
  • LIFECYCLE TESTING EMBEDDED SOFTWARE: MULTIPLE V-Model (3)
  • LIFECYCLE TESTING EMBEDDED SOFTWARE: MULTIPLE V-Model (3)
    • The nested V Model
      • The seemingly sequential 3-V-Model ignores functional decomposition of a system (into components)
      • Each stage of a simple V-Model can be applied/used to guide functional decomposition
        • The left (design): decomposition
        • The middle (build): parallel development
        • The right (test): integration of components
      • With decomposition, each component is separately subjected to the Multiple-V Model, and repeated for subcomponents, etc., giving rise to a ‘nested’ V-Model
  • LIFECYCLE TESTING EMBEDDED SOFTWARE: MULTIPLE V-Model (3)
    • Nested Multiple V-Model
      • Usually a simple V-Model is applied at the component level
      • For most systems, not the full system is initially designed, but a component (following the software architectural levels)
      • The simple V-Model (for components), when combined with multiple V-model (for the system/integration level), a “Nested Multiple V-model” results
  • LIFECYCLE TESTING EMBEDDED SOFTWARE: MULTIPLE V-Model (3)
  • LIFECYCLE TESTING EMBEDDED SOFTWARE: MULTIPLE V-Model (3)
  • LIFECYCLE TESTING EMBEDDED SOFTWARE: MULTIPLE V-Model (3)
    • Nested, Multiple V-Model allows, e.g., higher-level issues to be correctly placed within higher-level test issues, etc.