Your SlideShare is downloading. ×
  • Like
SOFTWARE CONSTRUCTION AND TESTING Software Construction
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

SOFTWARE CONSTRUCTION AND TESTING Software Construction

  • 346 views
Published

 

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
346
On SlideShare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
9
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 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 Project from 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. Software Construction & Testing - A Large Project from Inland Steel Industries, Inc. *
    • $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”
    * 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. Hierarchical View of Software Construction Statement (sequence, selection, iteration) EXAMPLES X = X + 1 MOVE ACCT TO NEWACCT IF X = 25... DO WHILE ... (one or more statements combine to form a module) Module (paragraph, procedure, subroutine) COMPUTE-NET-PAY SALESTAX(AMT,TOTAL) Program (one or more modules combine to form a program) INVOICE PROGRAM ORDER ENTRY PROGRAM ELEVATOR PROGRAM Sub-System or System (one or more programs combine to form a sub-system or system) H P P D S (software, hardware, people, procedures, data)
  • 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) Sub-System or System (one or more Class-with-Objects combine to form a sub-system or system) H P P D S (software, hardware, people, procedures, data) Class with Objects Attributes Services
  • 10.
    • TOP-DOWN
    • BOTTOM-UP
    • MIDDLE-OUT
    Software Construction Strategies
    • High-level to low-level; user interface to detail logic
    • Reverse of the above
    • Some of both
    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 High (best) Low (worst)
    • Functional
    • Informational
    • Communicational
    • Procedural
    • Temporal
    • Logical
    • Coincidental
  • 13. Cohesion* * adapted from: Software Engineering, Pressman, R. S., McGraw Hill, 1987 “ Scatter-brained” module “ Single-minded” module low (“worst”) high (“best”) Coincidental Logical Temporal ..... Informational Functional
  • 14. COHESION: The measure of strength of the interrelatedness of statements within a module High (best) Low (worst)
    • 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
  • 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 Logic to validate student id Logic to handle error condition Logic to prompt user for password Logic to ..... etc. Each of these is a separate module
  • 18. COUPLING: The measure of strength of the connection between modules High (worst) Low (best)
    • Content
    • Common
    • Control
    • Stamp
    • Data
    • No Coupling
  • 19. Coupling* * adapted from: Software Engineering, Pressman, R. S., McGraw Hill, 1987 “ highly independent” module “ highly dependent” module low (“best”) high (“worst”) No coupling Data Stamp Control Common Content
  • 20. COUPLING: The measure of strength of the connection between modules High (worst) Low (best)
    • 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
  • 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. Module A Stub B Stub C Stub D Module A Module B Stub C Stub D Stub E Stub F Module A Module B Stub C Stub D Module E Stub F Stub Testing (shaded module is the current one being tested)
  • 24. Module A Stub B Stub C Stub D Module A Do Stub B Do Stub C Do Stub D End Module A Stub B Display “ now in Stub B” Return Stub C Display “ now in Stub C” Return Stub D Display “ now in Stub D” Return Calling Stub Modules During Construction & Testing
  • 25. Systems Analysis Systems Design Software Design Program Design Module Design User Specification System Specification Software Specification Program Specification Module Specification Acceptance Testing System Testing Function Testing Integration Testing Unit Testing Programming Framework for Information Systems Testing
  • 26. Validation and Verification
    • Define the “Problem”
    • Solve the “Problem”
    • Prove it
      • Validation - process done by s/w developer
      • Verification - process done by customer
    1 of 2
  • 27. Validation and Verification 2 of 2 Need(s) Design and Implement Component Test Sub-system Test Sub-system Requirements System Requirements Component Requirements System Test Delivered System
  • 28. That’s all folks!