1 / 98

9. SYSTEM INTEGRATION

9. SYSTEM INTEGRATION . Software Engineering Roadmap: Chapter 9 Focus. Construct system in stages - Plan integration of parts to yield whole - Test subassemblies - Assemble in “builds” - Test whole system in a variety of ways. Identify corporate practices.

cirocco
Télécharger la présentation

9. SYSTEM INTEGRATION

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 9. SYSTEM INTEGRATION

  2. Software Engineering Roadmap: Chapter 9 Focus Construct system in stages - Plan integration of parts to yield whole - Test subassemblies - Assemble in “builds” - Test whole system in a variety of ways Identify corporate practices Plan project Maintain Analyze requirements Integrate & test system Design Implement Test units Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  3. Chapter Learning Goals • Be able to plan the integration of modules • Understand types of testing required • Be able to plan and execute testing • beyond the unit level Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  4. 1. Introduction to system integration

  5. Unified Process for Integration & Test Jacobson et al: USDP Requirements Analysis Design Implemen- tation Test Inception Elaboration Construction Transition Integration Unit Tests Integration tests ... System tests Prelim. iterations Iter. #1 Iter. #n Iter. #n+1 Iter. #m Iter. #m+1 Iter. #k ….. …..

  6. Development Overview Customer loss of information Requirements loss Architecture

  7. Development Overview Customer loss of information Requirements loss Architecture loss loss Detailed design Interface specs loss loss Function code Module (e.g., package) code After Myers System code

  8. Testing Units in Context Stand-alone unit test of function -- may require driver & stubs Test of function in context -- eliminate or reduce driver & stubs Function code Function tests code + Iteration or System code Complete code

  9. order of testing Testing Overview: Artifact Flow(After Myers) Requirements (11) Acceptance tests Docs. (10) Installation tests Architecture (9) Usability tests Docs. Docs. (8) System tests Detailed design (7) Regression tests Docs. Interface specs (6) Integration tests Function code Docs. (5) Interface tests Code + Code + Module (e.g., package) code (2),(4) Module tests Code + Code + (1),(3) Function tests Iteration or System code Complete code

  10. Testing forValidation and Verification(After Myers) (11) Acceptance tests* Tested against requirements (“validation”) Requirements (10) Installation tests*‡ (9) Usability tests*‡ (8) System tests*‡ (7) Regression tests* (1), (4) Function tests Includes… : *use-cases ‡performance testing

  11. Testing for Validation and Verification(After Myers) (11) Acceptance tests* Requirements (10) Installation tests*‡ “validation1” (9) Usability tests*‡ (8) System tests*‡ Architecture “verification2” (7) Regression tests* (6) Integration tests* Interface specs “verification2” (5) Interface tests (1), (4) Function tests “verification2” Detailed design (2), (3) Module tests Note 1: Tested against requirements Note 2: Tested against documents indicated Includes… : *use-cases ‡performance testing

  12. 2. The integration process

  13. Build 1 Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  14. Build 2 Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  15. Build 3 Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  16. Final Build of Single Level Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  17. Final Build of Double Level Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  18. The Build Process Single level iteration Double level iteration . . . . Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  19. Integration in Spiral Development Design Requirements analysis First iteration Second iteration 2. Design for additional requirements 1. Get additional requirements 3. Code additional 5. Test 4. Integrate new code Implementation Test Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  20. Relating Builds and Iterations in the Unified Process Jacobson et al: USDP Requirements Analysis Design Implemen- tation Test Inception Elaboration Construction Transition First build for iteration i Last build for iteration i Prelim. iterations Iter. #1 Iter. #n Iter. #n+1 Iter. #i Iter. #m Iter. #m+1 Iter. #k ….. ….. …..

  21. Typical Build 1 Module 1 2 3 4 Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  22. Typical Build 2 Module 1 2 3 4 Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  23. Unit-Oriented Build 1 Module 1 Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  24. Unit-Oriented Build 2 Module 1 2 3 4 Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  25. Unit-Oriented Build 3 Module 1 2 3 4 Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  26. Last Build Module 1 2 3 4 Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  27. Build Sequences: Ideal vs. Typical Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  28. 1. Understand the architecture decomposition. • try to make architecture simple to integrate 2. Identify the parts of the architecture that each iteration will implement. • build framework classes first, or in parallel • if possible, integrate “continually” • build enough UI to anchor testing • document requirements for each iteration • try to build bottom-up • so the parts are available when required • try to plan iterations so as to retire risks • biggest risks first • specify iterations and builds so that each use case is handled completely by one 3. Decompose each iteration into builds if necessary. 4. Plan the testing, review and inspection process. • see section tbd. 5. Refine the schedule to reflect the results. One way to ... Plan Integration& Builds Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  29. 1. Decide extent of all tests. Roadmap for Integration and System Test 2. For each iteration … 2.1 For each build … 2.2 Perform iteration system and usability tests -- see section tbd 3. Perform installation tests -- see section tbd 4. Perform acceptance tests -- see section tbd

  30. 1. Decide extent of all tests. Roadmap for Integration and System Test 2. For each iteration … 2.1 For each build … 2.1.1 Perform regression testing from prior build 2.1.2 Retest functions if required 2. 1.3 Retest modules if required 2. 1.4 Test interfaces if required 2. 1.5 Perform build integration tests -- section 3.1 Development of iteration complete 2.2 Perform iteration system and usability tests -- sections 3.4, 3.5 System implemented 3. Perform installation tests -- section 3.8 System installed 4. Perform acceptance tests -- section 3.7 Job complete

  31. RPG Video Game Architecture Packages -- built around the domain classes Characters «framework package» EncounterCharacters «uses» «application package» EncounterCharacter PlayerCharacter ForeignCharacter PlayerQualityWindow Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  32. RPG Video Game Architecture Packages -- built around the domain classes Framework layer GameEnvironment GameArtifacts «framework package» «framework package» RolePlayingGame Characters «framework package» «framework package» «uses» Application layer EncounterGame «uses» EncounterCharacters «application package» «application package» EncounterGame Engagement EncounterCharacter EngagementDisplay «uses» EncounterEnvironment PlayerCharacter «application package» ForeignCharacter Area EncounterAreaConnection PlayerQualityWindow ConnectionHyperlink Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  33. Factors Determining the Sequence of Integration • Usage of modules by other modules • build and integrate modules used before modulesthat use them • Defining and using framework classes • Exercising integration early • Exercising key risky parts of the application as early as possible • Showingparts or prototypes to customers technical (factors) risk reduction requirements Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  34. Integration Schedule Milestones Iterations Elaboration iterations Inception iteration Iteration 2 “elementary interaction” Iteration 1 “view characters in areas” Builds Modules

  35. Integration Schedule Month 1 Month 2 Month 3 Month 4 Month 5 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 Milestones Proto. requirements Complete prototype Iterations Elaboration iterations Inception iteration Iteration 2 “elementary interaction” Iteration 1 “view characters in areas” Builds build 1 build 3 build 2 . . . . . . . Modules Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  36. Integration Schedule Month 1 Month 2 Month 3 Month 4 Month 5 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 Milestones Proto. requirements Complete prototype Iterations Elaboration iterations Inception iteration Iteration 2 “elementary interaction” Iteration 1 “view characters in areas” Builds build 1 build 3 build 2 RolePlaying- Game package Characters package GameEn- vironment package Modules Encounter Characters package Encounter- Environ- ment package EncounterGame package Integrate & test Integrate & test Integrate & test Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  37. 3. The testing process

  38. Encounter Continual Integration week 3 RolePlayingGame EncounterGame Characters GameCharacter Layout EncounterCharacters EncounterLayout Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  39. Encounter Continual Integration week 7 RolePlayingGame RPGame EncounterGame Characters GameCharacter Layout EncounterCharacters Map EncounterLayout EncounterEnvironment «facade» EncounterCast «facade» Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  40. Encounter Continual Integration week 11 RolePlayingGame RPGame EncounterGame Characters GameCharacter Layout EncounterCharacters Map EncounterLayout EncounterEnvironment «facade» EncounterCast «facade» Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  41. RolePlayingGame Encounter Continual Integration week 15 RPGame EncounterGame Characters EncounterGame «facade» GameCharacter Layout EncounterCharacters Map Location EncounterCharacter EncounterLayout EncounterEnvironment «facade» EncounterCast «facade» Area Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  42. Plan and Execute Integration Tests One way to ... 1. Decide how and where to store, reuse and code the integration tests. • show this in the project schedule 2. Execute as many unit tests (again) as time allows • this time in the context of the build • no drivers or stubs required this time • prioritize by those most likely to uncover defects 3. Exercise regression tests • to ensure existing capability has not been compromised 4. Ensure build requirement are properly specified 5. Exercise use cases that the build should implement • test against the SRS 6. Execute the system tests supported by this build Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  43. Relationship Between Use Cases, Iterations and Builds Iteration 5 build 5.3 Use case 14

  44. Relationship between Use Cases, Iterations and Builds … 4 Iteration 5 … 6 5.2 build 5.3 5.4 Use case 7 * Use case 14 * * Use case 23 Use case 9 * «extends» or «includes» Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  45. Final Code Build and Integration Schedule: a Banking Example week 23 week 31 biweekly daily weekly code builds baseline release

  46. Final Code Build and Integration Schedule: a Banking Example week 23 week 31 biweekly daily weekly code builds baseline Integration of module into baseline bank query module release tasks bank deposit module bank withdrawal module Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  47. Typical Day-by-Day Code Integration Process biweekly daily weekly builds week 23 week 31 release

  48. Typical Day-by-Day Code Integration Process Run regression tests 6 pm 7 am development development time Confirm baseline or revert to previous baseline Freeze development biweekly daily weekly builds week 23 week 24 week 25 week 26 week 27 week 28 week 29 week 30 week 31 release = overnight regression test Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  49. Artifacts and Roles for Integration Testing* Component engineer Integration tester System tester Test engineer . . . . . . . . . . . . . . . . . . responsible for . . . . . . . . . . . . . . . . . . . . . . . . . . . .

  50. Artifacts and Roles for Integration Testing* Component engineer Integration tester System tester Test engineer . . . . . . . . . . . . . . . . . . responsible for . . . . . . . . . . . . . . . . . . . . . . . . . . . . Test evaluation  Use-case model Test plan Test procedure Test component Defect management Test case *Jacobson et al: USDP

More Related