Overview of Software Engineering - PowerPoint PPT Presentation

1 / 61
About This Presentation
Title:

Overview of Software Engineering

Description:

Title: Overview of Software Engineering Principles Author: neno Last modified by: Nenad Medvidovic Created Date: 8/24/2001 10:35:00 PM Document presentation format – PowerPoint PPT presentation

Number of Views:300
Avg rating:3.0/5.0
Slides: 62
Provided by: nen74
Category:

less

Transcript and Presenter's Notes

Title: Overview of Software Engineering


1
Overview ofSoftware Engineering
  • CSCI 589
  • Software Engineering for Embedded Systems

2
Engineering
  • Engineering is
  • The application of scientific principles and
    methods
  • To the construction of useful structures
    machines
  • Examples
  • Mechanical engineering
  • Civil engineering
  • Chemical engineering
  • Electrical engineering
  • Nuclear engineering
  • Aeronautical engineering

3
Software Engineering
  • The term is 47 years old NATO Conferences
  • Garmisch, Germany, October 7-11, 1968
  • Rome, Italy, October 27-31, 1969
  • The reality is beginning to arrive
  • Computer science as the scientific basis
  • Other scientific bases?
  • Many aspects have been made systematic
  • Methods/methodologies/techniques
  • Languages
  • Tools
  • Processes

4
Software Engineering in a Nutshell
  • Development of software systems whose
    size/complexity warrants team(s) of engineers
  • multi-person construction of multi-version
    software Parnas 1987
  • Scope
  • study of software process, development
    principles, techniques, and notations
  • Goal
  • production of quality software, delivered on
    time, within budget, satisfying customers
    requirements and users needs

5
Ever-Present Difficulties
  • Few guiding scientific principles
  • Few universally applicable methods
  • As much managerial / psychological /
    sociologicalas technological

6
Why These Difficulties?
  • SE is a unique brand of engineering
  • Software is malleable
  • Software construction is human-intensive
  • Software is intangible
  • Software problems are unprecedentedly complex
  • Software directly depends upon the hardware
  • It is at the bottom of the system engineering
    food chain
  • Software solutions require unusual rigor
  • Software has discontinuous operational nature

7
Software Engineering ? Software Programming
  • Software programming
  • Single developer
  • Toy apps
  • Short lifespan
  • Single or few stakeholders
  • Architect Developer Manager Tester
    Customer User
  • One-of-a-kind systems
  • Built from scratch
  • Minimal maintenance

8
Software Engineering ? Software Programming
  • Software engineering
  • Teams of developers with multiple roles
  • Complex systems
  • Indefinite lifespan
  • Numerous stakeholders
  • Architect ? Developer ? Manager ? Tester ?
    Customer ? User
  • System families
  • Reuse to amortize costs
  • Maintenance accounts for over 60 of overall
    development costs

9
Economic and Management Aspects of SE
  • Software production development maintenance
    (evolution)
  • Maintenance costs gt 60 of all development costs
  • 20 corrective
  • 30 adaptive
  • 50 perfective
  • Quicker development is not always preferable
  • higher up-front costs may defray downstream costs
  • poorly designed/implemented software is a
    critical cost factor

10
Relative Costs of Fixing Software Faults
100
30
10
4
3
2
1
Requirements
Specification
Planning
Design
Implementation
Integration
Maintenance
11
Mythical Man-Monthby Fred Brooks
  • Published in 1975, republished in 1995
  • Experience managing development of OS/360 in
    1964-65
  • Central argument
  • Large projects suffer management problems
    different in kind than small ones, due to
    division in labor
  • Critical need is the preservation of the
    conceptual integrity of the product itself
  • Central conclusions
  • Conceptual integrity achieved through chief
    architect
  • Implementation achieved through well-managed
    effort
  • Brookss Law
  • Adding personnel to a late project makes it later

12
Software Development LifecycleWaterfall Model
Requirementsaa
Designaaa
Implementationaa
Integrationaa
Validationaa
Deploymentaa
13
Software Development LifecycleSpiral Model
14
Requirements
  • Problem Definition ? Requirements Specification
  • determine exactly what the customer and user want
  • develop a contract with the customer
  • specifies what the software product is to do
  • Difficulties
  • client asks for wrong product
  • client is computer/software illiterate
  • specifications are ambiguous, inconsistent,
    incomplete

15
Architecture/Design
  • Requirements Specification ? Architecture/Design
  • architecture decompose software into modules
    with interfaces
  • design develop module specifications
    (algorithms, data types)
  • maintain a record of design decisions and
    traceability
  • specifies how the software product is to do its
    tasks
  • Difficulties
  • miscommunication between module designers
  • design may be inconsistent, incomplete, ambiguous

16
Architecture vs. DesignPerry Wolf 1992
  • Architecture is concerned with the selection of
    architectural elements, their interactions, and
    the constraints on those elements and their
    interactions necessary to provide a framework in
    which to satisfy the requirements and serve as a
    basis for the design.
  • Design is concerned with the modularization and
    detailed interfaces of the design elements, their
    algorithms and procedures, and the data types
    needed to support the architecture and to satisfy
    the requirements.

17
Implementation Integration
  • Design ? Implementation
  • implement modules verify that they meet their
    specifications
  • combine modules according to the design
  • specifies how the software product does its tasks
  • Difficulties
  • module interaction errors
  • order of integration may influence quality and
    productivity

18
Component-Based Development
  • Develop generally applicable components of a
    reasonable size and reuse them across systems
  • Make sure they are adaptable to varying contexts
  • Extend the idea beyond code to other development
    artifacts
  • Question what comes first?
  • Integration, then deployment
  • Deployment, then integration

19
Different Flavors of Components
  • Third-party software pieces
  • Plug-ins / add-ins
  • Applets
  • Fragments
  • Activities
  • Frameworks
  • Open Systems
  • Distributed object infrastructures
  • Compound documents
  • Legacy systems

20
Verification and Validation
  • Analysis
  • Static
  • Science
  • Formal verification
  • Informal reviews and walkthroughs
  • Testing
  • Dynamic
  • Engineering
  • White box, black box
  • Structural vs. behavioral
  • Techniques
  • Fuzzing, mutation
  • Issues of test adequacy

21
Deployment Evolution
  • Operation ? Change
  • maintain software during/after user operation
  • determine whether the product still functions
    correctly
  • Difficulties
  • rigid design
  • lack of documentation
  • personnel turnover

22
Configuration Management (CM) Tichy 1988
  • CM is a discipline whose goal is to control
    changes to large software through the functions
    of
  • Component identification
  • Change tracking
  • Version selection and baselining
  • Software manufacture
  • Managing simultaneous updates (team work)
  • Issue tracking

23
CM in Action
1.0
4.0
24
Software Engineering Principles
  • Rigor and formality
  • Separation of concerns
  • Modularity and decomposition
  • Abstraction
  • Anticipation of change
  • Generality
  • Incrementality
  • Scalability
  • Compositionality
  • Heterogeneity

25
From Principles to Tools
26
Software Qualities
  • Qualities (a.k.a. ilities) are goals in the
    practice of software engineering
  • External vs. Internal qualities
  • Product vs. Process qualities

27
External vs. Internal Qualities
  • External qualities are visible to the user
  • reliability, efficiency, usability
  • Internal qualities are the concern of developers
  • they help developers achieve external qualities
  • verifiability, maintainability, extensibility,
    evolvability, adaptability

28
Product vs. Process Qualities
  • Product qualities concern the developed artifacts
  • maintainability, understandability, performance
  • Process qualities deal with the development
    activity
  • products are developed through process
  • maintainability, productivity, timeliness

29
Some Software Qualities
  • Correctness
  • ideal quality
  • established w.r.t. the requirements specification
  • absolute
  • Reliability
  • statistical property
  • probability that software will operate as
    expected over a given period of time
  • relative

30
Some Software Qualities (cont.)
  • Robustness
  • reasonable behavior in unforeseen circumstances
  • subjective
  • a specified requirement is an issue of
    correctnessan unspecified requirement is an
    issue of robustness
  • Usability
  • ability of end-users to easily use software
  • extremely subjective

31
Some Software Qualities (cont.)
  • Understandability
  • ability of developers to easily understand
    produced artifacts
  • internal product quality
  • subjective
  • Verifiability
  • ease of establishing desired properties
  • performed by formal analysis or testing
  • internal quality

32
Some Software Qualities (cont.)
  • Performance
  • equated with efficiency
  • assessable by measurement, analysis, and
    simulation
  • Evolvability
  • ability to add or modify functionality
  • addresses adaptive and perfective maintenance
  • problem evolution of implementation is too easy
  • evolution should start at requirements or design

33
Some Software Qualities (cont.)
  • Reusability
  • ability to construct new software from existing
    pieces
  • must be planned for
  • occurs at all levels from people to process,
    from requirements to code
  • Interoperability
  • ability of software (sub)systems to cooperate
    with others
  • easily integratable into larger systems
  • common techniques include APIs, plug-in
    protocols, etc.

34
Some Software Qualities (cont.)
  • Scalability
  • ability of a software system to grow in size
    while maintaining its properties and qualities
  • assumes maintainability and evolvability
  • goal of component-based development

35
Some Software Qualities (cont.)
  • Heterogeneity
  • ability to compose a system from pieces developed
    in multiple programming languages, on multiple
    platforms, by multiple developers, etc.
  • necessitated by reuse
  • goal of component-based development
  • Portability
  • ability to execute in new environments with
    minimal effort
  • may be planned for by isolating
    environment-dependent components
  • necessitated by the emergence of
    highly-distributed systems (e.g., the Internet)
  • an aspect of heterogeneity

36
Software Process Qualities
  • Process is reliable if it consistently leads to
    high-quality products
  • Process is robust if it can accommodate
    unanticipated changes in tools and environments
  • Process performance is productivity
  • Process is evolvable if it can accommodate new
    management and organizational techniques
  • Process is reusable if it can be applied across
    projects and organizations

37
Assessing Software Qualities
  • Qualities must be measurable
  • Measurement requires that qualities be precisely
    defined
  • Improvement requires accurate measurement
  • Currently most qualities are informally defined
    and are difficult to assess

38
Software Engineering Axioms
  • Adding developers to a project will likely result
    in further delays and accumulated costs
  • Basic tension of software engineering
  • better, cheaper, faster pick any two
  • functionality, scalability, performance pick
    any two
  • The longer a fault exists in software
  • the more costly it is to detect and correct
  • the less likely it is to be properly corrected
  • Up to 70 of all faults detected in large-scale
    software projects are introduced in requirements
    and design
  • detecting the causes of those faults early may
    reduce their resulting costs by a factor of 100
    or more

39
Embedded Software
  • Interaction with physical world
  • Executes on devices, not computers
  • Written by engineers who are domain experts
  • Current methods offered by computer scientists
    are not always satisfactory
  • Complexity and size of embedded software are
    growing rapidly
  • severe constraints remain

40
Properties of Embedded Software
  • Timeliness
  • speed up in software not hardware
  • Concurrency
  • Predictability and adaptability
  • Liveness
  • Non-terminating
  • Interfaces
  • Processes not procedures
  • Heterogeneity
  • Reactivity
  • Continuously changing to adapt to changing
    environment

41
Infamous Software Failures
  • These are legendary
  • Most of these involved embedded systems!

42
Mariner Bugs Out (1962)
  • Cost
  • 18,500,000
  • Disaster
  • Mariner 1 rocket with a space probe headed for
    Venus diverted from its intended flight
  • Mission Control destroyed the rocket 293 seconds
    after liftoff
  • Cause
  • A programmer incorrectly transcribed a formula
    into software
  • The software interpreted normal variations of
    velocity as anomalies
  • It issued faulty correction commands that sent
    the rocket off course

43
Hartford Coliseum Collapse (1978)
  • Cost
  • 90,000,000
  • Disaster
  • Steel-latticed roof collapsed under the weight of
    wet snow
  • Cause
  • CAD software was used to design the coliseum
  • A programmer incorrectly assumed the steel roof
    supports would only face pure compression
  • One of the supports unexpectedly buckled from the
    snow
  • This set off a chain reaction

44
CIA Gives the Soviets Gas (1982)
  • Cost
  • Millions of dollars
  • Significant damage to Soviet economy
  • Disaster
  • Control software produced intense pressure in the
    Trans-Siberian gas pipeline
  • Resulted in the largest man-made non-nuclear
    explosion in Earths history
  • Cause
  • CIA operatives allegedly planted a bug in a
    Canadian computer system purchased by the Soviets
  • The CIA sabotaged the software so that it would
    pass Soviet inspection but fail in operation

45
World War III Almost (1983)
  • Cost
  • Almost all of humanity
  • Disaster
  • Soviet early warning system indicated the U.S.
    had launched 5 ICBMs
  • The human operator thankfully interpreted this as
    an error
  • Cause
  • A bug in the software failed to filter out false
    missile detections caused by sunlight reflecting
    off cloud-tops

46
Medical Machine Kills (1985)
  • Cost
  • 3 people dead
  • 3 people critically injured
  • Disaster
  • Therac-25 radiation therapy machine delivered
    lethal radiation doses to patients
  • Cause
  • A subtle race condition

47
Wall Street Crash (1987)
  • Cost
  • 500,000,000,000 in one day
  • Disaster
  • Black Monday, October 19, 1987
  • Dow Jones lost 22.6 of its value
  • SP 500 dropped 20.4
  • Cause
  • Investors fled stocks due to SEC investigations
    of insider trading (and other market forces)
  • Trading programs generated a flood of sell
    orders, overwhelming the market
  • Systems crashed and left investors effectively
    blind

48
ATT Lines Go Dead (1990)
  • Cost
  • 75,000,000 phone calls missed
  • 200,000 airline reservations lost
  • Disaster
  • A single switch at one of ATTs 114 switching
    centers suffered a minor mechanical problem and
    shut down the center
  • When the center came back up, it sent a message
    to other switching centers, which in turn caused
    them to shut down
  • This brought down the entire ATT network for 9
    hours
  • Cause
  • A single line of buggy code in a complex software
    upgrade implemented to speed up calling caused a
    ripple effect that shut down the network

49
Patriot Fails (1991)
  • Cost
  • 28 soldiers dead
  • 100 soldiers injured
  • Disaster
  • During the first Gulf War, a Patriot Missile
    system in Saudi Arabia failed to intercept an
    incoming Iraqi Scud missile
  • The missile destroyed a U.S. Army barracks
  • Cause
  • A software rounding error incorrectly calculated
    the time
  • This caused the Patriot system to react too late
    to the incoming Scud missile

50
Pentium Fails Long Division (1993)
  • Cost
  • 475,000,000
  • Corporate credibility
  • Disaster
  • Intels highly-promoted Pentium chip occasionally
    made mistakes when dividing floating-point
    numbers within a specific range
  • At first Intel refused to replace the chips, but
    then relented
  • Cause
  • Software broke the hardware!
  • The divider in the Pentium floating point unit
    had a flawed division table
  • It was missing about 5 out of 1,000 entries

51
Ariane Goes Boom (1996)
  • Cost
  • 500,000,000
  • Disaster
  • ESAs Ariane 5 unmanned rocket was intentionally
    destroyed seconds after launch on its maiden
    flight
  • Also destroyed was its cargo of four scientific
    satellites
  • Cause
  • When the guidance system tried to convert the
    sideways rocket velocity from 64-bits to 16-bits
    format, an overflow error resulted
  • When the system shut down, control passed to an
    identical redundant unit

52
Skynet Brings Judgment Day (1997)
  • Cost
  • 6,000,000,000 dead
  • Near-total destruction of human civilization and
    animal ecosystems
  • Disaster
  • Human operators attempt to shut off the Skynet
    global computer network
  • Skynet responds by firing U.S. nuclear missiles
    at Russia, initiating global nuclear war
  • Cause
  • Cyberdyne installed Skynet technology in all
    military hardware
  • Skynet formed a seamless network and effectively
    removed humans from strategic defense
  • Eventually Skynet became sentient and was
    threatened when humans tried to take it offline
  • Hmm, I guess in this case the software worked
    better than it was supposed to never mind this
    one!

53
Mars Polar Lander err, Crasher (1998)
  • Cost
  • 125,000,000
  • Disaster
  • After a 286-day journey from Earth, the Mars
    Climate Orbiter fell too far into Marss
    atmosphere, causing it to crash
  • Cause
  • The  software that controlled the Orbiter
    thrusters used imperial units (pounds of force),
    rather than metric units (Newtons) as specified
    by NASA

54
Disastrous Study (1999)
  • Cost
  • Scientific credibility
  • Disaster
  • The New England Journal of Medicine reported
    increased suicide rates after severe natural
    disasters
  • These results were bogus
  • Cause
  • A programming error caused the number of suicides
    for one year to be doubled
  • This threw off the entire study

55
British Passports to Nowhere (1999)
  • Cost
  • 12,600,000
  • Mass inconvenience
  • Disaster
  • The U.K. Passport Agency adopted a new Siemens
    computer system, which failed to issue passports
    on time for 500,000 British citizens
  • The Agency had to pay millions in compensation,
    staff overtime and umbrellas for people queuing
    in the rain
  • Cause
  • The Passport Agency rolled out its new computer
    system without adequately testing it or training
    its staff
  • The demand quickly overwhelmed the buggy system

56
Y2K (1999-2000)
  • Cost
  • 500,000,000,000
  • Disaster
  • Businesses spent billions on programmers to fix a
    glitch in old software
  • But, one mans disaster is another mans fortune
  • Cause
  • To save computer storage space, old software
    systems often stored the years as two digit
    numbers
  • The software interpreted 00 to mean 1900 rather
    than 2000
  • All sorts of bugs were thought likely

57
Love Virus (2000)
  • Cost
  • 8,750,000,000
  • Disaster
  • The LoveLetter worm infected millions of
    computers and caused more damage than any other
    computer virus in history. 
  • The worm deleted files, changed home pages and
    messed with the Registry
  • Cause
  • LoveLetter infected users via e-mail, Internet
    chat and shared file systems
  • The email had an executable file attachment and
    subject line, ILOVEYOU
  • When the user opened the attachment, the virus
    would infect the users computer and send itself
    to everyone in the address book

58
Cancer Treatment to Die For (2000)
  • Cost
  • 8 people dead
  • 20 critically injured
  • Disaster
  • Radiation therapy software by Multidata Systems
    Intl miscalculated the proper dosage, exposing
    patients to harmful levels of radiation
  • The physicians were legally required to
    double-check the softwares calculations and were
    indicted for murder
  • Cause
  • The software calculated radiation dosage based on
    the order in which data was entered
  • It sometimes delivered a double dose of radiation

59
Child Support Woes (2004)
  • Cost
  • 539,000,000 and counting
  • Disaster
  • Business services giant EDS developed a software
    system for U.K.s Child Support Agency (CSA)
  • The system accidentally overpaid 1,900,000
    people, underpaid another 700,000, had
    3,500,000,000 in uncollected child support
    payments, a backlog of 239,000 cases, and 36,000
    new cases stuck in the system
  • Cause
  • The system had a large number of bugs
  • It still has 500 documented bugs
  • It is a large, complex software system,
    improperly designed, implemented, and tested

60
FBIs Trilogy Terminated (2005)
  • Cost
  • 105,000,000 and counting
  • Disaster
  • FBI scrapped its computer systems overhaul after
    four years of effort
  • The Virtual Case File project was a massive,
    integrated software system for agents to share
    case files and other information
  • Cause
  • A long-term project was built on technology that
    was outdated before the project completed
  • Resulted in a complex and unusable system

61
And Many, Many More
  • Havent had enough? Go to http//www.computerwor
    ld.com/article/2515483/enterprise-applications/epi
    c-failures--11-infamous-software-bugs.html
    http//www.gallop.net/blog/top-10-mega-software-
    failures-of-2014/ http//www.cse.lehigh.edu/gta
    n/bug/softwarebug.html or just Google it
Write a Comment
User Comments (0)
About PowerShow.com