300 likes | 580 Views
SOFTWARE CONSTRUCTION AND TESTING. 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?
E N D
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?
Software Construction & Testing • Labor intensive activity • Tools are required • Blueprints are essential • Mistakes can be deadly • Weariness and Stress are common
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
$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.
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
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
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
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)
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
Two Software Evaluation Metrics Cohesion Coupling
COHESION: The measure of strength of the interrelatedness of statements within a module • Functional • Informational • Communicational • Procedural • Temporal • Logical • Coincidental High (best) Low (worst)
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
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)
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
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
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.
COUPLING: The measure of strength of the connection between modules • Content • Common • Control • Stamp • Data • No Coupling High (worst) Low (best)
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
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)
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
Software Testing Methodology Showing Feedback/Fallback Loop User Acceptance Testing System Testing Function Testing Integration Testing Unit Testing
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
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
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
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
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