Software Engineering Principles and Practice Third Edition Hans

Скачать презентацию Software Engineering Principles and Practice Third Edition Hans

fb0217f4bcfacfea7ee2f7bfe3e7f84e.ppt

Количество слайдов: 48

Software engineering The beginning § 1968/69 NATO conferences: introduction of the term Software Engineering § Idea: software development is not an art, or a bag of tricks § Build software like we build bridges § Conferences held in response to Software Crisis § Errors in software, software late, over-budget © 2008 John Wiley & Sons Ltd. www. wileyeurope. com/college/van vliet 3

Further references § Henry Petroski, Design Paradigms: Case Histories of Error and Judgement in Engineering § A. Spector & D. Gifford, A Computer Science Perspective of Bridge Design, Comm. Of the ACM 29, 4 (1986) p 267 -283 © 2008 John Wiley & Sons Ltd. www. wileyeurope. com/college/van vliet 7

Is Building Software ~ Building Bridges? § Yes, and no § Bridge building has taken place for thousands of years – compared to 40 years of software engineering § Public is more forgiving with software failures than bridge collapses § Software is logical, rather than physical § Progress is hard to see with software § Software is not continuous § § Branch of mathematics for bridge building is calculus Computer scientists use discrete mathematics more. © 2008 John Wiley & Sons Ltd. www. wileyeurope. com/college/van vliet 8

Relative distribution of software/hardware costs 100 Percent of total cost Hardware Development 60 Software 20 1955 © 2008 John Wiley & Sons Ltd. www. wileyeurope. com/college/van vliet Maintenance 1970 Year 1985 9

What is Software Engineering? § Software engineering concerns methods and techniques to develop large software systems. § The engineering metaphor is used to emphasize a systematic approach to developing systems that satisfy organizational requirements and constraints. © 2008 John Wiley & Sons Ltd. www. wileyeurope. com/college/van vliet 10

First Definition of Software Engineering § Software engineering is the establishment and use of sound engineering principles in order to obtain economically software that is reliable and works efficiently on real machines. © 2008 John Wiley & Sons Ltd. www. wileyeurope. com/college/van vliet 11

Alternate Definition of Software Engineering § Software Engineering is a discipline that aims to create fault-free software on time, within budget, to meet the needs of the customer. § The software should be easy to maintain. © 2008 John Wiley & Sons Ltd. www. wileyeurope. com/college/van vliet 12

Definition (IEEE) 1) Software Engineering is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software 2) The study of approaches as in 1) © 2008 John Wiley & Sons Ltd. www. wileyeurope. com/college/van vliet 13

Essential Characteristics of Software Engineering § Software engineering concerns the development of large programs § NASA Space shuttle § 40 million lines of object code – 30 times as much as Saturn V § The central theme is mastering complexity § Separation of concerns helps. § Software evolves as opposed to wearing out § The efficiency with which software is developed is of crucial importance § Regular cooperation between people is an integral part of programming-in-the-large § The software has to support its users effectively. § Software engineering is a field in which members of one culture create artifacts on behalf of members of another culture. § Software engineering is a balancing act.

Simple life cycle model problem requirements analysis reqs specification design implementation system testing working system maintenance © 2008 John Wiley & Sons Ltd. www. wileyeurope. com/college/van vliet 15

Waterfall Life Cycle Model Figure 2. 8

Waterfall Model (contd) § Characterized by § § § Feedback loops Documentation-driven Liked by managers § Advantages § § Documentation associated with each phase Maintenance is easier § Disadvantages § § Specification document hard for customer to understand No feedback from the customer until the end

Requirements Phase § yields a description of the desired system: § § which functions possible extensions required documentation (artifacts) performance requirements § often preceded by a feasibility study § requirements are elicited from stakeholders (elicitation techniques include interviews, questionnaires, etc. ) § resulting document: Requirements Definition (customer oriented) § document describes what to do not how © 2008 John Wiley & Sons Ltd. www. wileyeurope. com/college/van vliet 18

Analysis Phase § also called the Specification Phase § resulting artifact is the Software Requirements Specification (SRS) § document is developer-oriented § in the object-oriented paradigm, developers perform two steps during this phase § They determine what should the product do § They extract the classes for the system § together the Requirements and Analysis Phases comprise the Requirements Analysis Phase

Design Phase § The Design Phase has two sub-phases: § Architectural Design § Detailed Design § During Architectural Design, the modules are decided upon § There is a decomposition into parts/components; what are the functions of, and interfaces between, those components? § The emphasis in Architectural Design is what rather than how. There may be a Design Specification Document. § During the Detailed Design Phase, the data structures and algorithms are determined. § The algorithms may be written in pseudocode. © 2008 John Wiley & Sons Ltd. www. wileyeurope. com/college/van vliet 20

Implementation § The algorithms are translated to code § goal: a working, flexible, robust, … piece of software § not a bag of tricks © 2008 John Wiley & Sons Ltd. www. wileyeurope. com/college/van vliet 21

Missing Steps from Waterfall Model § testing phases and documentation are not shown in the depiction of the Waterfall Model here § Why? Testing and documentation are a part of every phase

Testing § does the software do what it is supposed to do? § are we building the right system? § (validation) § Customer-oriented § are we building the system right (correctly)? § (verification) § Developer-oriented § An artifact such as the design is correct with respect to the SRS § Traceability is a concern – Forward and backward traceability § start testing activities in phase 1, on day 1 © 2008 John Wiley & Sons Ltd. www. wileyeurope. com/college/van vliet 23

Post-Delivery Maintenance § correcting errors found after the software has been delivered § adapting the software to changing requirements, changing environments, . . . © 2008 John Wiley & Sons Ltd. www. wileyeurope. com/college/van vliet 24

Development distribution of effort § rule of thumb: 40 -20 -40 distribution of effort. Only about 20% of effort is spent on coding § trend: enlarge requirements specification/design slots; reduce test slot § beware: maintenance alone consumes 50 -75% of total effort. Notice the figures above do not include post-delivery maintenance. © 2008 John Wiley & Sons Ltd. www. wileyeurope. com/college/van vliet 26

Kinds of maintenance activities § corrective maintenance: fixing errors § Example: a logic error is causing incorrect output § adaptive maintenance: changes due to the environment (both hardware and software) § Example: The US Postal Service increases its postal rates § perfective maintenance: changes to the system based on changing user requirements § Example: The user requests additional functionality or wants a more efficient system. © 2008 John Wiley & Sons Ltd. www. wileyeurope. com/college/van vliet 27

Point to ponder #1 § Is this a good model § of how we go about development? § of how we should go about development? § We will come back to these questions. © 2008 John Wiley & Sons Ltd. www. wileyeurope. com/college/van vliet 29

Example Software Failure: Space Shuttle Software § Cost: $10 Billion, millions of dollars more than planned § Time: 3 years late § Quality: First launch of Columbia was cancelled because of a synchronization problem with the Shuttle's 5 onboard computers. § § § Error was traced back to a change made 2 years earlier when a programmer changed a delay factor in an interrupt handler from 50 to 80 milliseconds. The likelihood of the error was small enough, that the error caused no harm during thousands of hours of testing. Substantial errors still exist. § Astronauts are supplied with a book of known software problems "Program Notes and Waivers".

Examples of Software Failures § Blaster worm (Fall 2003) § Machines running Microsoft infected - worldwide § Y 2 K Problem (Late 90’s) § Numerous software changes due to insufficient planning § Ariane 5 rocket explosion (1996) § $500 million loss b/c inadequate testing, inappropriate reuse § Patriot anti-missile shield failure (Gulf War -1991) § 28 Americans killed and 98 wounded due to insufficient testing § Therac-25 (1987) § 2 patients died of radiation overdose due to software fault

More Software Failures § Year 1900 Bug (1992) § Woman who is 104 receives kindergarten invitation § Leap-year Bug (1988) § Supermarket fined $1000 § Interface Misuse (1990) § Train left the station without its driver § Denver International Airport (1995) § Airport opened 16 mo. late, $3. 2 billion over-budget § US Treasury Department (2003) § 50, 000 Social Security checks printed without beneficiary’s name

ARIANE Flight 501 § Disintegration after 39 sec § Caused by large correction for altitude deviation § Caused by wrong data being sent to On Board Computer § Caused by software exception in Inertial Reference System after 36 sec. – 2 SRIs in parallel © 2008 John Wiley & Sons Ltd. www. wileyeurope. com/college/van vliet 33

The details § Overflow in conversion of variable BH from 64 -bit floating point to 16 -bit signed integer § Of 7 risky conversions, 4 were protected; BH was not § Reasoning: physically limited, or large margin of safety § In case of exception: report failure on databus and shut down © 2008 John Wiley & Sons Ltd. www. wileyeurope. com/college/van vliet 34

Inadequate testing? § Specification does not contain Ariane 5 trajectory data as a functional requirement § In tests, the SRI’s (components that measure altitude and movements of the launcher) were simulated by software modules § Committee investigating crash exposed error through extensive simulations © 2008 John Wiley & Sons Ltd. www. wileyeurope. com/college/van vliet 36

Improper reuse? § If a component works perfectly well in one environment, it doesn’t necessarily do so in another § Ariane 5 is much faster than Ariane 4, and horizontal velocity builds up more rapidly excessive values for parameter in question § Wish for quick alignment after hold in shutdown this software runs for a while after lift-off. It doesn’t have any purpose for the Ariane 5, but was still kept © 2008 John Wiley & Sons Ltd. www. wileyeurope. com/college/van vliet 37

Wrong design philosophy? § If something breaks down, such as caused by a random hardware failure § Action: shut down that part § There was no provision for design errors in the software. § In case of a software failure, which is not random, an identical backup is of little use. § Suggestion: A component could have been asked to give best estimate of situation. © 2008 John Wiley & Sons Ltd. www. wileyeurope. com/college/van vliet 38

Quo Vadis? Where is SE Going? § It takes at least 15 -20 years for a technology to become mature; this also holds for computer science: UNIX, relational databases, structured programming, … § Software engineering has made tremendous progression § There is no silver bullet, though © 2008 John Wiley & Sons Ltd. www. wileyeurope. com/college/van vliet 40

Recent developments § Rise of agile methods § Shift from producing software to using software § Success of Open Source Software § Software development becomes more heterogeneous © 2008 John Wiley & Sons Ltd. www. wileyeurope. com/college/van vliet 41

Return to Point to Ponder #1 Is the Waterfall Model a good model § of how we go about development? § of how we should go about development? Agile methods provide an alternative approach. © 2008 John Wiley & Sons Ltd. www. wileyeurope. com/college/van vliet 42

The Agile Manifesto § Individuals and interactions over processes and tools § Working software over comprehensive documentation § Customer collaboration over contract negotiation § Responding to change over following a plan © 2008 John Wiley & Sons Ltd. www. wileyeurope. com/college/van vliet 43

Producing software Using software § Builders build pieces, integrators integrate them § Component-Based Development (CBSD) § Software Product Lines (SPL) § Commercial Off-The-Shelves (COTS) § Service Oriented Applications (SOA) © 2008 John Wiley & Sons Ltd. www. wileyeurope. com/college/van vliet 44

Open Source: crowdsourcing 1. 2. 3. 4. Go to LEGO site Use CAD tool to design your favorite castle Generate bill of materials Pieces are collected, packaged, and sent to you 5. Leave your model in LEGO’s gallery 6. Most downloaded designs are prepackaged q No requirements engineers needed! q Gives rise to new business model © 2008 John Wiley & Sons Ltd. www. wileyeurope. com/college/van vliet 45

Heterogeneity § Old days: software development department had everything under control § Nowadays: § Teams scattered around the globe § Components acquired from others § Includes open source parts § Services found on the Web © 2008 John Wiley & Sons Ltd. www. wileyeurope. com/college/van vliet 46

Point to ponder #2 § Which of the following do you consider as Software Engineering Principles? § § § § Build with and for reuse Define software artifacts rigorously Establish a software process that provides flexibility Manage quality as formally as possible Minimize software components interaction Produce software in a stepwise fashion Change is inherent, so plan for it and manage it Tradeoffs are inherent, so make them explicit and document them § Uncertainty is unavoidable, so identify and manage it © 2008 John Wiley & Sons Ltd. www. wileyeurope. com/college/van vliet 47

SUMMARY § software engineering is a balancing act, where trade-offs are difficult § solutions are not right or wrong; at most they are better or worse § most of maintenance is (inevitable) evolution § there are many life cycle models, and they are all models © 2008 John Wiley & Sons Ltd. www. wileyeurope. com/college/van vliet 48