1 / 20

EEE 243B Applied Computer Programming

EEE 243B Applied Computer Programming. Software engineering Life cycle and when to test. Review. What is the difference between white box and black box testing? What does coverage give you?. Outline. Software engineering (what is it?) Basic software lifecycle Verification and validation

lee-silva
Download Presentation

EEE 243B Applied Computer Programming

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. EEE 243BApplied Computer Programming Software engineering Life cycle and when to test

  2. Review • What is the difference between white box and black box testing? • What does coverage give you? Maj JGA Beaulieu & Capt MWP LeSauvage

  3. Outline • Software engineering (what is it?) • Basic software lifecycle • Verification and validation • Testing revisited Maj JGA Beaulieu & Capt MWP LeSauvage

  4. Software engineering • Software engineering came of age as the demand on software products increased • The first few software programs were written by one person for his/her own purpose • These programs were small and were produced and used by experts • The flexibility afforded by software created a high demand and the number of projects and the size of the projects grew exponentially Maj JGA Beaulieu & Capt MWP LeSauvage

  5. Software engineering • Software production was no longer an individual affair but became a team approach • As the teams grew bigger and the complexity of the software projects increased a requirement grew to better manage these projects • Some costly project delays, dropping quality of products and utter project failures in the late 1960s created what was called the software crisis Maj JGA Beaulieu & Capt MWP LeSauvage

  6. Software engineering • Software engineering: Is a label that is normally applied to a set of current (best) practices for software development Shaw and Garland 1996 • Software engineering was first coined as an expression during a NATO conference in 1968 • The conference was created to address the problems brought on by the software crisis Maj JGA Beaulieu & Capt MWP LeSauvage

  7. Software engineering • Engineering disciplines share five common traits: • Creating cost effective solutions – economical aspect • Solving practical problems – solutions that matter to the population (customer) • Apply scientific knowledge – science, math, analysis and design • Build things – tangible results • Work in the service of mankind – Not just a customer Maj JGA Beaulieu & Capt MWP LeSauvage

  8. Basic software lifecycle • The quality of your software depends on all production activities: • Analysis – Will your program meet the needs of the user (client)? • Design – Is my design effective? Did I do a good decomposition and create a “readable” hierarchy of modules (high level) and functions (low level)? Did you chose the right design • Implementation – Is the code solid, efficient, well documented, complete? • Testing – Are my tests sufficient? • Maintenance – Did I introduce side effects during changes Maj JGA Beaulieu & Capt MWP LeSauvage

  9. Basic software lifecycle • The 5 phases that we saw are often represented graphically as a waterfall; hence the waterfall model: Analysis Design Implementation Testing Maintenance Maj JGA Beaulieu & Capt MWP LeSauvage

  10. Verification and Validation • There are parts of the testing that has nothing to do with the code!! …Really there is. • When you have elicited requirements as part of your analysis of the problem, you must test the requirements with your end user • This test is called Validation • Validation can occur at more than one stage of the software lifecycle Maj JGA Beaulieu & Capt MWP LeSauvage

  11. Verification and Validation • When you finish your design, you must ensure that you took into account all the requirements from analysis. • So you test between these two phases • This extends to the entire lifecycle: • Every time you go from one phase to the next, you have to make sure you did not overlook anything, and • that each phase is complete and agrees with the results of the previous phase • This phase transition testing is called Verification Maj JGA Beaulieu & Capt MWP LeSauvage

  12. Verification and Validation • Verification and validation (V&V) ensure that you catch potentials errors before you get to the code and testing of the code. • The reason for performing V&V at all stages of a project is to reduce the impact of changes later in the lifecycle • Correcting a mistake at the end of the project may require you to start back at the analysis stage! Maj JGA Beaulieu & Capt MWP LeSauvage

  13. Verification and Validation • Verification ensures that each subsequent phase does not deviate from the requirement of the project • If a deviation from the project must occur for the product to work, then the verification process must identify and track this deviation • Verification ensures that the product is built to the right requirement - building the product right Maj JGA Beaulieu & Capt MWP LeSauvage

  14. Verification and Validation • The first thing you try to do is to ensure that you have the requirement right • So validation has to do with building the right product • You may sometimes have to build a prototype or scaffolding in a software project to validate with the customer and get feedback Maj JGA Beaulieu & Capt MWP LeSauvage

  15. Testing revisited • The scaffolding that you build as a prototype can also be used for testing purposes • In structured programming, we use a top-down approach to decompose our problems during the design phase • When we implement our design, we have two choices: • Bottom-up implementation • Top-down implementation Maj JGA Beaulieu & Capt MWP LeSauvage

  16. Testing revisited • In bottom-up implementation, it may sometimes be necessary to provide input to or get output from a module or a function • In this case a driver can be used to simulate the input and get the output, as if the function under test was already part of a bigger system • Drivers in a scaffolding may only be a few lines of code, but they provide all the necessary environment needed by lower functions Maj JGA Beaulieu & Capt MWP LeSauvage

  17. Testing revisited • In top-down implementation, it may be necessary for the upper modules or functions to obtain some results from lower functions • In this case, we can provide a stub in the scaffolding to generate the necessary data needed by the upper function Maj JGA Beaulieu & Capt MWP LeSauvage

  18. Testing revisited • Many projects use both the top-down and the bottom-up approaches simultaneously. • In these cases the scaffolding may include both drivers and stubs • Stubs and drivers are small functions that form a scaffolding until the system is ready for integration • Integration testing may use scaffolding, to perform incremental testing as we integrate functions one at a time Maj JGA Beaulieu & Capt MWP LeSauvage

  19. Testing revisited • Acceptance testing is the last phase of validation and is normally conducted in presence of the customer • Most large software producers also have a Quality Assurance department that can represent and assist the customer • For commercial software the QA department is the “customer” Maj JGA Beaulieu & Capt MWP LeSauvage

  20. Quiz Time • What are the five phases of the software lifecycle? • What is the difference between verification and validation? • What is the difference between a driver and a stub? Maj JGA Beaulieu & Capt MWP LeSauvage

More Related