11-SoftwareEngineeringx - Computer Science Department

offbeatnothingSoftware and s/w Development

Dec 2, 2013 (3 years and 6 months ago)

97 views

Software Engineering

Week 11

INFM 603

Agenda


Software Development


Software Process Models


Testing


Note: Software Engineering material based
on slides from cmsc132 (
Dept

of CS,
UMCP)

Modern Software Development


Why do we want to study the software development
process?


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
fails


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.99
o

to
E180


Raptor pilots visually followed refueling tankers back to
Hawaii



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
-
of
-
all
-
time/


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
component


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
maintenance


Problems


User documentation


Help users understand how to use software


Technical documentation


Help coders understand how to modify, maintain
software

Maintenance


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
order


Begin new step
only when
previous step is
complete


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
Model

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
features

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
deployment


Tools for managing, tracking, performing statistics on such
bugs and vulnerabilities essential, particularly on large
projects


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


Miscellaneous


Generating documentation using
javadoc