Chapter 3

740 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
740
On SlideShare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
10
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Chapter 3

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

×