SOFTWARE CONSTRUCTION AND TESTING

1. SOFTWARE CONSTRUCTION AND TESTING

2. Software Construction & Testing • What is software construction? • What is software testing? • How important are construction & testing? • What are some of the “critical success factors” for construction & testing? • Who should be involved in the construction & testing activities?

3. Software Construction & Testing • Labor intensive activity • Tools are required • Blueprints are essential • Mistakes can be deadly • Weariness and Stress are common

4. Software Construction & Testing - A Large Projectfrom LORAL (formerly IBM Federal Systems Div) * • Flight Software in Space Shuttle 500 KLOC • Software Production Facility Simulator 1,700 KLOC • Mission & Payload Control Centers 4,000 KLOC • Launch Processing System 2,500 KLOC • Space Lab (prototype version) 800 KLOC Total: 9,500 KLOC • New Version every 4-8 months • 10-53 KLOC changes each time * circa 1994

5. $4.6B Revenue (#6) $74.4M I.S. Budget 466 I.S. Employees Order Fulfillment Sys 27 Integrated Applics. 18 Reeng bus. process Almost 4 years: 1993 - Feas & Analysis ‘94-’96 Dev, Imple. in 3 phases 400 Person-years with 200 technologists Replaced 30-year old sys 65,000 Function Points 7 Million LOC Cost: $37M; Save: $25M (one-time); $9M Annually Developed On-Time and Within Budget - aka “A Miracle” Software Construction & Testing -A Large Project from Inland Steel Industries, Inc. * * Caldwell, Bruce, “Taming the Beast”, InformationWeek, 3/10/97, pp 38-48.

6. Software Construction & Testing - Software Design Principles • Software should work correctly • Software must conform to requirements specification • Software must be reliable over time and data • Software must be evolutionary • Software must be easy to use • Software should be easy to test & implement • Software should use computer resources efficiently

7. Verification and Validation* • Verification: The process of evaluating a system or component to determine whether the products of a given phase satisfy the conditions imposed at the start of that phase. (Mainly a paper-based activity that requires you to confirm that each stage of the development conforms to the requirements defined in the previous stage.) • Validation: The process of evaluating a system or component during or at the end of the development process to determine whether it satisfies specified requirements. (Mainly a confirmation that the implemented system/component actually works to specification.) * IEEE Standard Glossary of Software Engineering Terminology, 1994

8. EXAMPLES X = X + 1 MOVE ACCT TO NEWACCT IF X = 25... DO WHILE ... Statement (sequence, selection, iteration) (one or more statements combine to form a module) COMPUTE-NET-PAY SALESTAX(AMT,TOTAL) Module (paragraph, procedure, subroutine) (one or more modules combine to form a program) INVOICE PROGRAM ORDER ENTRY PROGRAM ELEVATOR PROGRAM Program (one or more programs combine to form a sub-system or system) H S Sub-System or System P D P (software, hardware, people, procedures, data) Hierarchical View of Software Construction

9. Hierarchical View of Object-Oriented Software Construction Statement (sequence, selection, iteration) (one or more statements combine to form a service) Service (one or more services belong to a Class or Class-with-Objects) Class with Objects Attributes Services (one or more Class-with-Objects combine to form a sub-system or system) H S P D Sub-System or System P (software, hardware, people, procedures, data)

10. Software Construction Strategies • High-level to low-level; user interface to detail logic • Reverse of the above • Some of both • TOP-DOWN • BOTTOM-UP • MIDDLE-OUT These strategies are discussed in more detail in the Testing Section

11. Two Software Evaluation Metrics Cohesion Coupling

12. COHESION: The measure of strength of the interrelatedness of statements within a module • Functional • Informational • Communicational • Procedural • Temporal • Logical • Coincidental High (best) Low (worst)

13. Cohesion* Coincidental Logical Temporal ..... Informational Functional high (“best”) low (“worst”) “Scatter-brained” module “Single-minded” module * adapted from: Software Engineering, Pressman, R. S., McGraw Hill, 1987

14. COHESION: The measure of strength of the interrelatedness of statements within a module • Functional - one action or goal • Informational - multiple independent actions on • the same data • Communicational - series of steps on same data • Procedural - series of steps for an action • Temporal - series of related actions related in time • Logical - series of related actions • Coincidental - multiple, unrelated actions High (best) Low (worst)

15. Cohesion - examples - 1 of 3 • Coincidental cohesion module Logic to produce Payroll report Logic to produce Production report Logic to produce Sales report Logic to check e-mail etc... One module

16. Cohesion - examples - 2 of 3 • With (x) = Coincidental cohesion • Without (x) = Logical cohesion Display date & time on screen Prompt user for student id number Look up student id number in STUDENT table IF found: Prompt user for password Validate password Process course seat registration request Check to see if user has email waiting (x) Check to see if user’s health record is up-to-date (x) ELSE IF not found: do error processing END

17. Cohesion - examples - 3 of 3 • Functionally cohesive modules Logic to display date Logic to display time Logic to prompt user for student id Each of these is a separate module Logic to validate student id Logic to handle error condition Logic to prompt user for password Logic to ..... etc.

18. COUPLING: The measure of strength of the connection between modules • Content • Common • Control • Stamp • Data • No Coupling High (worst) Low (best)

19. Coupling* No coupling Data Stamp Control Common Content high (“worst”) low (“best”) “highly independent” module “highly dependent” module * adapted from: Software Engineering, Pressman, R. S., McGraw Hill, 1987

20. COUPLING: The measure of strength of the connection between modules • Content - direct branch into middle of module • Common - global reference of variables • Control - control element being passed • Stamp - pass an entire data structure • Data - variables or fields only being passed • No Coupling High (worst) Low (best)

21. Software Testing Principles • User-accepted test plan • General testing strategy/philosophy: • Cause and discover errors • Rules of reasonableness should prevail • Testing Strategies: • Top-Down • Bottom-Up • Middle-out • Hybrid • Black box • White box • Alpha • Beta

22. Software Testing Methodology Showing Feedback/Fallback Loop User Acceptance Testing System Testing Function Testing Integration Testing Unit Testing

23. Stub Testing (shaded module is the current one being tested) Module A Stub B Stub C Stub D Module A Module B Stub C Stub D Stub F Stub E Module A Module B Stub C Stub D Stub F Module E

24. Calling Stub Modules During Construction & Testing Module A Stub B Stub C Stub D Module A Do Stub B Do Stub C Do Stub D End Module A Stub C Display “now in Stub C” Return Stub B Display “now in Stub B” Return Stub D Display “now in Stub D” Return

25. Framework for Information Systems Testing Acceptance Testing System Testing Function Testing Integration Testing Unit Testing Systems Analysis Systems Design Software Design Program Design Module Design User Specification System Specification Software Specification Program Specification Module Specification Programming

26. 1 of 2 Validation and Verification • Define the “Problem” • Solve the “Problem” • Prove it • Validation - process done by s/w developer • Verification - process done by customer

27. 2 of 2 Validation and Verification Need(s) Delivered System System Requirements System Test Sub-system Requirements Sub-system Test Component Requirements Component Test Design and Implement

28. That’s all folks!