We think you have liked this presentation. If you wish to download it, please recommend it to your friends in any social system. Share buttons are a little bit lower. Thank you!
Presentation is loading. Please wait.
Published byAshley Bascom
Modified over 2 years ago
Slide 15.1 © The McGraw-Hill Companies, 2002 Object-Oriented and Classical Software Engineering Fifth Edition, WCB/McGraw-Hill, 2002 Stephen R. Schach firstname.lastname@example.org
Slide 15.2 © The McGraw-Hill Companies, 2002 CHAPTER 15 IMPLEMENTATION AND INTEGRATION PHASE
Slide 15.3 © The McGraw-Hill Companies, 2002 Overview l Implementation and integration l Testing during the implementation and integration phase l Integration testing of graphical user interfaces l Product testing l Acceptance testing l CASE tools for the implementation and integration phase l CASE tools for the complete software process
Slide 15.4 © The McGraw-Hill Companies, 2002 Overview (contd) l Integrated environments l Environments for business applications l Public tool infrastructures l Potential problems with environments l Metrics for the implementation and integration phase l Air Gourmet Case Study: Implementation and integration phase l Challenges of the implementation and integration phase
Slide 15.5 © The McGraw-Hill Companies, 2002 Implementation and Integration Phase l Up to now: Implementation followed by integration –Poor approach l Better –Combine implementation and integration methodically
Slide 15.6 © The McGraw-Hill Companies, 2002 Product with 13 Modules
Slide 15.7 © The McGraw-Hill Companies, 2002 Implementation, Then Integration l Code and test each module separately l Link all 13 modules together, test product as a whole
Slide 15.8 © The McGraw-Hill Companies, 2002 Drivers and stubs l To test module a, modules b, c, d must be stubs –Empty module, or –Prints message ("Procedure radarCalc called"), or –Returns precooked values from preplanned test cases To test module h on its own requires a driver, which calls it –Once, or –Several times, or –Many times, each time checking value returned Testing module d requires driver and two stubs
Slide 15.9 © The McGraw-Hill Companies, 2002 Implementation, Then Integration (contd) l Problem 1 –Stubs and drivers must be written, then thrown away after module testing is complete l Problem 2 –Lack of fault isolation –A fault could lie in any of 13 modules or 13 interfaces –In a large product with, say, 103 modules and 108 interfaces, there are 211 places where a fault might lie l Solution to both problems –Combine module and integration testing –“Implementation and integration phase”
Slide 15.10 © The McGraw-Hill Companies, 2002 Top-down Implementation and Integration l If module m1 calls module m 2, then m1 is implemented and integrated before m2 l One possible top-down ordering is –a, b, c, d, e, f, g, h, i, j, k, l, m l Another possible top-down ordering is – a –[a]b, e, h –[a]c, d, f, i –[a, d]g, j, k, l, m
Slide 15.11 © The McGraw-Hill Companies, 2002 Top-down Implementation and Integration (contd) l Advantage 1: Fault isolation –Previously successful test case fails when mNew is added to what has been tested so far l Advantage 2: Stubs not wasted –Stub expanded into corresponding complete module at appropriate step
Slide 15.12 © The McGraw-Hill Companies, 2002 Top-down Implementation and Integration (contd) l Advantage 3: Major design flaws show up early –Logic modules include decision-making flow of control »In the example, modules a, b, c, d, g, j –Operational modules perform actual operations of module »In the example, modules e, f, h, i, k, l, m l Logic modules are developed before operational modules
Slide 15.13 © The McGraw-Hill Companies, 2002 Top-down Implementation and Integration (contd) l Problem 1 –Reusable modules are not properly tested –Lower level (operational) modules are not tested frequently –The situation is aggravated if the product is well designed l Defensive programming (fault shielding) –Example: if (x >= 0) y = computeSquareRoot (x, errorFlag); –Never tested with x < 0 –Reuse implications
Slide 15.14 © The McGraw-Hill Companies, 2002 Bottom-up Implementation and Integration l If module m1 calls module m2, then m 2 is implemented and integrated before m1 –One possible bottom-up ordering is l, m, h, i, j, k, e, f, g, b, c, d, a –Another possible bottom- up ordering is h, e, b i, f, c, d l, m, j, k, g[d] a[b, c, d]
Slide 15.15 © The McGraw-Hill Companies, 2002 Bottom-up Implementation and Integration (contd) l Advantage 1 –Operational modules thoroughly tested l Advantage 2 –Operational modules are tested with drivers, not by fault shielding, defensively programmed calling modules l Advantage 3 –Fault isolation
Slide 15.16 © The McGraw-Hill Companies, 2002 Bottom-up Implementation and Integration (contd) l Difficulty 1 –Major design faults are detected late l Solution –Combine top-down and bottom-up strategies making use of their strengths and minimizing their weaknesses
Slide 15.17 © The McGraw-Hill Companies, 2002 Sandwich Implementation and Integration l Logic modules are implemented and integrated top-down l Operational modules are implemented and integrated bottom- up l Finally, the interfaces between the two groups are tested
Slide 15.18 © The McGraw-Hill Companies, 2002 Sandwich Implementation and Integration (contd) l Advantage 1 –Major design faults are caught early l Advantage 2 –Operational modules are thoroughly tested –They may be reused with confidence l Advantage 3 –There is fault isolation at all times
Slide 15.19 © The McGraw-Hill Companies, 2002 Summary
Slide 15.20 © The McGraw-Hill Companies, 2002 Object-Oriented Implementation and Integration l Object-oriented implementation and integration –Almost always sandwich implementation and integration –Objects are integrated bottom-up –Other modules are integrated top-down
Slide 15.21 © The McGraw-Hill Companies, 2002 Management Issues during Implem. and Int. l Example –Design document used by Team 1 (who coded module m1 ) shows m1 calls m2 passing 4 parameters –Design document used by Team 2 (who coded module m2 ) states clearly that m2 has only 3 parameters l Solution –The implementation and integration. process must be run by SQA
Slide 15.22 © The McGraw-Hill Companies, 2002 Testing during Implem. and Integration Phase l Product testing –Performed to ensure that the product will not fail its acceptance test l Failing the acceptance test is a disaster for management –The client may conclude that the developers are incompetent –Worse, the client may believe that the developers tried to cheat l The SQA team must ensure that the product passes its acceptance test
Slide 15.23 © The McGraw-Hill Companies, 2002 Integration Testing of Graphical User Interfaces l GUI test cases: –Mouse clicks –Key presses –And so on l Cannot be stored in the usual way l We need special CASE tools l Examples: –QAPartner –XRunner
Slide 15.24 © The McGraw-Hill Companies, 2002 Strategy for Product Testing l The SQA team must try to approximate the acceptance test l Black box test cases for the product as a whole l Robustness of product as a whole –Stress testing (under peak load) –Volume testing (e.g., can it handle large input files?)
Slide 15.25 © The McGraw-Hill Companies, 2002 Strategy for Product Testing (contd) l Check all constraints –Timing constraints –Storage constraints –Security constraints –Compatibility l Review all documentation to be handed over to the client l Verify the documentation against the product l The product (software plus documentation) is now handed over to the client organization for acceptance testing
Slide 15.26 © The McGraw-Hill Companies, 2002 Acceptance Testing l The client determines whether the product satisfies its specifications l Performed by –The client organization, or –The SQA team in the presence of client representatives, or –An independent SQA team hired by the client
Slide 15.27 © The McGraw-Hill Companies, 2002 Acceptance Testing (contd) l Four major components of acceptance testing –Correctness –Robustness –Performance –Documentation l (Precisely what was done by developer during product testing)
Slide 15.28 © The McGraw-Hill Companies, 2002 CASE tools for the Implem. and Integ. Phase l Bare minimum: –Version control tools –Examples: »rcs, sccs, PCVS, SourceSafe
Slide 15.29 © The McGraw-Hill Companies, 2002 CASE Tools for the Complete Software Process l A large organization needs an environment l A medium-sized organization can probably manage with a workbench l A small organization can usually manage with just tools.
Slide 15.30 © The McGraw-Hill Companies, 2002 Integrated Environments l Usual meaning of “integrated” –User interface integration –Similar “look and feel” –Most successful on the Macintosh l There are also other types of integration
Slide 15.31 © The McGraw-Hill Companies, 2002 Process Integration l Environment supports one specific process l Subset: Technique-based environment –Formerly: “method-based environment” –Supports specific technique –Examples: »Structured systems analysis »Petri nets –Usually comprises »Graphical support for specification, design phases »Data dictionary »Some consistency checking »Some management support –Support and formalization of manual processes –Examples: »Analyst/Designer, Rose, Rhapsody (for Statecharts)
Slide 15.32 © The McGraw-Hill Companies, 2002 Technique-Based Environments (contd) l Advantage of technique-based environment –Forced to use specific method, correctly l Disadvantages of technique-based environment –Forced to use specific method –Inadequate support of programming-in-the-many
Slide 15.33 © The McGraw-Hill Companies, 2002 Environments for Business Application l The emphasis is on ease of use –GUI –Standard forms for input, output –Code generator »Detailed design is lowest level of abstraction »Expect productivity rise l Examples: –Foundation, Bachman Product Set
Slide 15.34 © The McGraw-Hill Companies, 2002 Public Tool Infrastructure l PCTE—Portable common tool environment –NOT an environment –An infrastructure for supporting CASE tools (similar to the way an operating system provides services for user products) –Adopted by ECMA (European Computer Manufacturers Association) l Example implementations: –IBM, Emeraude
Slide 15.35 © The McGraw-Hill Companies, 2002 Potential Problems with Environments l No one environment is ideal for all organizations –Each has its strengths and weaknesses l Warning 1 –Choosing the wrong environment can be worse than no environment –Enforcing a wrong technique is counterproductive l Warning 2 –Shun environments below CMM level 3 –We cannot automate a nonexistent process –A CASE tool or CASE workbench is fine
Slide 15.36 © The McGraw-Hill Companies, 2002 Metrics for the Implem. and Integ. Phase l The five basic metrics, plus l Complexity metrics l Number of test cases, percentage which resulted in failure l Total number of faults, by types
Slide 15.37 © The McGraw-Hill Companies, 2002 Air Gourmet Case Study: Impl. and Integ. Phase l Complete C++ implementation, l Complete Java implementation, –at www.mhhe.com/engcs/compsci/schach
Slide 15.38 © The McGraw-Hill Companies, 2002 Challenges of the Implem. and Integration Phase l Management issues are paramount here –Appropriate CASE tools –Test case planning –Communicating changes to all personnel –Deciding when to stop testing
CS451 Software Implementation and Integration Yugi Lee STB #555 (816) Note: This lecture was designed.
Software Engineering Zhang Shuang
Implementation & Integration Phase Implementation, then integration: Implementation, then integration: Each module is implemented by member of programmer.
Integration testing Integrate two or more module.i.e. communicate between the modules. Follow a white box testing (Testing the code)
1 Implementation Xiaojun Qi. 2 Choice of Programming Language The language is usually specified in the contract But what if the contract specifies that.
Slide 13.1 © The McGraw-Hill Companies, 2002 Object-Oriented and Classical Software Engineering Fifth Edition, WCB/McGraw-Hill, 2002 Stephen R. Schach.
Illinois Institute of Technology
Slide 15.1 Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved. Object-Oriented and Classical Software Engineering Eighth Edition,
Integration testing Satish Mishra
ECE 355: Software Engineering
What is a level of test? Defined by a given Environment Environment is a collection of people, hard ware, software, interfaces, data etc.
TESTING LEVELS Unit Testing Integration Testing System Testing Acceptance Testing.
Chapter 10 Software Engineering. Understand the software life cycle. Describe the development process models. Understand the concept of modularity in.
CS 240, Prof. Sarwar Slide 1 CS 240: Software Project Fall 2003 Sections 1 & 2 Dr. Badrul M. Sarwar San Jose State University Lecture #18.
CSC 480 Software Engineering Test Planning. Test Cases and Test Plans A test case is an explicit set of instructions designed to detect a particular class.
Testing Basics of Testing Presented by: Vijay.C.G – Glister Tech.
Unit 251 Implementation and Integration Implementation Unit Testing Integration Integration Approaches.
CMSC 345, Version 11/07 SD Vick from S. Mitchell Software Testing.
Lab/Sessional -CSE-374. SYSTEM DEVELOPMENT LIFE CYCLE.
1 Integration Testing CS 4311 I. Burnstein. Practical Software Testing, Springer-Verlag, 2003.
Defect testing Objectives
Software Testing Sudipto Ghosh CS 406 Fall 99 November 9, 1999.
Testing i. explain the importance of system testing and installation planning;
Testing Workflow In the Unified Process and Agile/Scrum processes.
Software System Integration
Computers Are Your Future Tenth Edition Chapter 13: Systems Analysis & Design Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall1.
Extreme Programming Software Development Written by Sanjay Kumar.
Software Testing Reference: Software Engineering, Ian Sommerville, 6 th edition, Chapter 20.
CS540 Software Design Lecture 8 1 Lecture 8: Structured Design Anita S. Malik Adapted from Schach (2004) Chapter 13 and Appendix.
9 1 Chapter 9 Database Design Database Systems: Design, Implementation, and Management, Seventh Edition, Rob and Coronel.
Slide 6.1 CHAPTER 6 TESTING. Slide 6.2 Overview l Quality issues l Nonexecution-based testing l Execution-based testing l What should be tested? l Testing.
Software Testing & Strategies
1 Phase Testing. Janice Regan, For each group of units Overview of Implementation phase Create Class Skeletons Define Implementation Plan (+ determine.
Slide 10.1 © The McGraw-Hill Companies, 2002 Object-Oriented and Classical Software Engineering Fifth Edition, WCB/McGraw-Hill, 2002 Stephen R. Schach.
INT-Evry (Masters IT– Soft Eng)IntegrationTesting.1 (OO) Integration Testing What: Integration testing is a phase of software testing in which.
Programming Logic and Design Fourth Edition, Introductory
1 The System life cycle 16 The system life cycle is a series of stages that are worked through during the development of a new information system. A lot.
HNDIT23082 Lecture 09:Software Testing. Validations and Verification Validation and verification ( V & V ) is the name given to the checking and analysis.
Slide 1.1 © The McGraw-Hill Companies, 2002 Object-Oriented and Classical Software Engineering Fifth Edition, WCB/McGraw-Hill, 2002 Stephen R. Schach
Unit 241 Integration Phase The objective of this section is to introduce how the software product is realized from a set of programs, program units or.
Outline Types of errors Component Testing Testing Strategy
Testing. Definition From the dictionary- the means by which the presence, quality, or genuineness of anything is determined; a means of trial. For software.
The Software Development Process
1 Software testing. 2 Testing Objectives Testing is a process of executing a program with the intent of finding an error. A good test case is in that.
Software Testing Process By: M. Muzaffar Hameed.
… and after unit testing …
CS3320-Chap21 Office Hours TR 1:00-2:15 PM W 2:30-3:30 PM By appointment.
© 2017 SlidePlayer.com Inc. All rights reserved.