11-SoftwareEngineering.pptx - Department of Computer Science

Document Sample
11-SoftwareEngineering.pptx - Department of Computer Science Powered By Docstoc
					Software Engineering

       Week 11
      INFM 603
•   Software Development
•   Software Process Models
•   Testing
•   Note: Software Engineering material based
    on slides from cmsc132 (Dept of CS,
   Modern Software Development
• Why do we want to study the software development
   – To understand
      • Software development problems
      • Why software projects fail
      • Impact of software failures
      • How to develop better software
          Software Engineering
• Definition from Wikipedia
  – Field that creates and maintains software applications by
    applying technologies and practices from computer science,
    project management, engineering, application domains, and
    other fields
  Software Development Problems
• Software is
 • Expensive
    – Cost per line of code growing (unlike hardware)
 • Frequently late
    – Schedule overruns
    – Example: ARIS (Achievement Reporting and Innovation
      System) is an $80 million data and information system for
      New York City public schools which was not ready by
      Sept 2008 (due date). Complete article at:
       • http://www.nytimes.com/2008/10/24/education/24aris.html
 Software Development Problems
• Software is
  – More expensive than projected
    • Cost overruns
  – Difficult to use & understand
  – Missing features
  – Too slow
           Software Projects Fail
• Anywhere from 25-50% of custom software
• Example (FBI Virtual Case File)
  – Began Jan 2001
  – Officially scrapped Jan 2005
  – LA Times (Jan 13, 2005)
  – “A new FBI computer program designed to help agents
    share information to ward off terrorist attacks may have to
    be scrapped… Sources said about $100 million would be
    essentially lost if the FBI were to scrap the software…”
          Software Projects Fail
• Reasons for failure of FBI Virtual Case File
  – Poor specification
     • 800-page requirement document
     • Repeated changes in specification
     • New requirements continually added
  – Poor management
     • Repeated management turnover
     • Micromanagement of software developers
     • FBI personnel with no software experience
 Impact of Software Failures Increasing
• Software becoming part of basic infrastructure
   – Software in cars, appliances
   – Business transactions moving online
• Computers becoming increasingly connected
   – Failures can propagate through internet
      • Internet worms
   – Failures can be exploited by others
      • Viruses
      • Spyware
   Software Contributes to Real Failures
• Bugs in software may cause real-world failures
• Example – Air Force F-22A Raptor
   – Stealth fighter costing $300 million each
   – 1.7 millions lines of code for plane’s avionics
   Software Contributes to Real Failures
• Air Force F-22A Raptor software fails midair
    – DefenseNews.com (March 5, 2007)
    – “When a dozen Raptors en route from Hawaii to Japan
      crossed the International Date Line for the first time, the
      jets’ Global Positioning System navigation avionics went
      haywire, forcing the pilots to turn around.”
    – GPS software unable to handle change in longitude from
      W179.99o to E180
    – Raptor pilots visually followed refueling tankers back to
  Software Contributes to Real Failures
• Happy ending for Raptor?
  – Lockheed-Martin provided software fix in 48 hours
  – For “operational security reasons” the USAF declined to
    elaborate, saying only that the F-22A “experienced a
    software problem involving the navigation system”
• Tough being a Raptor test pilot
  – DefenseNews.com (March 5, 2007)
  – “When the plane was in developmental stages … pilots
    flying the Raptor would often have to reboot the onboard
    computers that controlled the jet’s high-end functions”
    Other Famous Software Failures
•  1990 AT&T long distance calls fail for 9 hours
    – Wrong location for C break statement
• 1996 Ariane rocket explodes on launch
    – Overflow converting 64-bit float to 16-bit integer
• 1999 Mars Climate Orbiter crashes on Mars
    – Missing conversion of English units to metric units
 • Other Failures available at:
    –   http://www.sundoginteractive.com/sunblog/posts/top-ten-most-infamous-software-bugs-
    –   http://www.net-security.org/secworld.php?id=10354
   Why Is Software So Difficult?
• Complexity
  – Software becoming much larger
     • Millions of line of code
     • Hundreds of developers
  – Many more interacting pieces
• Length of use
  – Software stays in use longer
     • Features & requirements change
     • Data sets increase
     • Can outlast its creators
            Software Life Cycle
• Coding is only part of software development
• Software engineering requires
  – Preparation before writing code
  – Follow-up work after coding is complete
• Software life cycle
  – List of essential operations / tasks
     • Needed for developing good software
  – No universal agreement on details
Components of Software Life Cycle
1.   Problem specification
2.   Program design
3.   Algorithms and data structures
4.   Coding and debugging
5.   Testing and verification
6.   Documentation and support
7.   Maintenance
        Software Development
• Coding is small part of software development
• Estimated % of time
  –   35%   Specification, design
  –   20%   Coding, debugging
  –   30%   Testing, reviewing, fixing
  –   15%   Documentation, support
          Problem Specification
• Goal
  – Create complete, accurate, and unambiguous statement of
    problem to be solved
• Example
  – Specification of input & output of program

• Problems
  – Description may be inaccurate or change over time
  – Difficult to specify behavior for all inputs
               Program Design
• Goal
  – Break software into integrated set of components that work
    together to solve problem specification
• Example

• Problems
  – Methods for decomposing problem
  – How components work together
  Algorithms and Data Structures
• Goal
  – Select algorithms and data structures to implement each
• Problems
  – Functionality
     • Provides desired abilities
  – Efficiency
     • Provides desired performance
  – Correctness
     • Provides desired results
  Algorithms and Data Structures
• Example
  – Implement list as array or linked list
           Coding and Debugging
• Goal
   – Write actual code and ensure code works
• Problems
   – Choosing programming language
       • Procedural design
           – Fortran, BASIC, Pascal, C
       • Object-oriented design
           – Smalltalk, C++, Java
   – Using language features
       • Exceptions, streams, threads
         Testing and Verification
• Goal
  – Demonstrate software correctly match specification
• Problem
  – Program verification
     • Formal proof of correctness
     • Difficult / impossible for large programs
  – Empirical testing
     • Verify using test cases
         – Unit tests, integration tests, alpha / beta tests
     • Used in majority of cases in practice
     Documentation and Support
• Goal
  – Provide information needed by users and technical
• Problems
  – User documentation
     • Help users understand how to use software
  – Technical documentation
     • Help coders understand how to modify, maintain
• Goal
   – Keep software working over time
• Problems
   – Fix errors
   – Improve features
   – Meet changing specification
   – Add new functionality
          Software Process Models
• Software methodology
   – Codified set of practices
   – Repeatable process for producing quality software
• Software process model
   – Methodology for organizing software life cycle
   – Major approaches
       • Waterfall model
       • Iterative development
            o Unified model
            o Agile software development
                 o Extreme programming (XP) (Prominent Example)
       • Formal methods
              Waterfall Model
• Approach
  – Perform steps in
  – Begin new step
    only when
    previous step is
  – Result of each step
    flow into next step
                 Waterfall Model
• Advantages
   – Simple
   – Predictable results (emphasizes predictability)
      • Software follows specifications
   – Reasonable for small projects
• Problems
   – In real life
      • May need to return to previous step
      • Steps may be more integrated
      • Steps may occur at same time
   – Unworkable for large projects
  Iterative Software Development
• Approach
  – Iteratively add incremental improvements
  – Take advantage of what was learned from earlier versions
    of the system
  – Use working prototypes to refine specifications
   Iterative Software Development
• Goals
   – Emphasize adaptability instead of predictability
   – Respond to changes in customer requirements
• Examples
   – Unified model
   – Agile software development
   – Extreme programming (XP)
                     Unified Model
• Development divided into phases (iterations)
  –   Inception
  –   Elaboration
  –   Construction
  –   Transition
• During each phase
  – Multiple iterations of software development
  – Development treated as mini-waterfalls
  – Emphasis gradually shifts from specification to testing
Unified Software Life Cycle
    Agile Software Development
• Agile approach
  – Based on iterative development
     • Short iterations (timeboxes) lasting 1- 4 weeks
  – Working software as principal measure of progress
     • Produced at end of each iteration
  – Adds a more people-centric viewpoint
     • Face-to-face communication preferred
     • Co-locate programmers, testers, “customers”
  – Relies on adapting to feedback rather than planning as the
    primary control mechanism
     • Less specification & documentation
Agile Methods
     Extreme Programming (XP)
• Prominent example of Agile methodology
   – Iterative, adaptive software development
• Describes set of day-to-day practices
   – Followed by managers & programmers
   – Intended to encourage a set of values
• Appropriate for environments with
   – Small teams
   – Rapidly-changing requirements
     Extreme Programming Values
• Communication
   – Rapidly building & disseminating institutional knowledge
     among programming team
• Simplicity
   – Implement simplest code needed by customer without
     emphasis on future versions
• Feedback
   – From testing, team members, customers
• Courage
   – Willingness to rewrite / refactor software to add or change
   Extreme Programming Practices
• Pair programming
   – Pairs of programmers combine software development
     efforts at one computer
   – Especially useful for novice programmers
• Test-driven development
   – Tests are designed first, before writing software
• Continuous integration
   – Tests performed throughout development process
• On-site customer
   – Customer available at all times to answer questions
  The Rapid Prototyping Model
• Goal: explore requirements
  – Without building the complete product
• Start with part of the functionality
  – That will (hopefully) yield significant insight
• Build a prototype
  – Focus on core functionality, not in efficiency
• Use the prototype to refine the requirements
• Repeat the process, expanding functionality
 Objectives of Rapid Prototyping
• Quality
  – Build systems that satisfy the real requirements
    by focusing on requirements discovery
• Affordability
  – Minimize development costs by building the
    right thing the first time
• Schedule
  – Minimize schedule risk by reducing the chance
    of requirements discovery during coding
               Formal Methods
• Mathematically-based techniques for
  – Specification, development, and verification
  – Software and hardware systems
• Intended for high-integrity systems
  – Safety
  – Security
• Levels
  – 0 – Informal implementation of formal specifications
  – 1 – Formal code development & verification
  – 2 – Theorem prover to ensure correctness
                Program Testing
• Empirical testing
  – Test software with selected test cases
  – More scalable than verification
  – Test failures frequently indicate software errors
     • Absence of failures doesn’t prove software correct
  – If code isn’t exercised by any test, hard to have confidence
    in it
     • Even if it has been “formally verified”
                 Kinds of Testing
• Automated testing
   – The software is tested by a completely automatic process
       • e.g., jUnit or submit server testing
   – Can be expensive or difficult to construct, but fairly cheap
     to repeat
• Manual testing
   – A person uses the software, perhaps guided by a script, and
     notes bugs
   – Often easier to conduct than writing test cases, but very
     expensive to repeat
              Types of Testing
• Clear box testing
  – Allowed to examine code
  – Attempt to improve thoroughness of tests
• Black box testing
  – No knowledge of code
  – Treat program as “black box”
  – Test behavior in response to inputs
             Testing Terminology
• Test case
   – Individual test
• Test suite
   – Collection of test cases
• Test harness
   – Program that executes a series of test cases
• Test framework
   – Software that facilitates writing & running tests
   – Example  JUnit
      • Lets see an example using Java
 • Regression Testing
          Why Regression Test?
• Running regression tests give developer much more
  freedom to change existing code
   – “I need to rewrite this component to support new
     functionality – I wonder if anything might be
     depending on the details of how it works now?”
• This freedom is key to agile development, and important
  even in more structured development methodologies
                     Bug Tracking
   Dilbert Comic - http://dilbert.com/strips/comic/1995-11-13/
   Even with good processes, (alleged) bugs will still turn up in
    system-level products, both in development and in
   Tools for managing, tracking, performing statistics on such
    bugs and vulnerabilities essential, particularly on large
   Tools
     –   Bugzilla  http://www.bugzilla.org/
     –   Jira  http://www.atlassian.com/software/jira/overview
                Bug Counting
   How good a metric of software quality is
    “number of outstanding bugs”?
   Are there other reasons you (as a manager)
    might want to introduce it as a metric?
   What would you expect to be the most
    immediate effect if you introduced it as a
    metric (and tied programmer appraisal to it)?
 Debugging is harder than coding!
“Debugging is twice as hard as writing the code
 in the first place. Therefore, if you write the
 code as cleverly as possible, you are, by
 definition, not smart enough to debug it”
    – Brian W. Kernighan and P. J. Plauger, The
                       Elements of Programming
   Generating documentation using javadoc

Shared By:
wu yunyi wu yunyi
About wuyyok@163.com