chapter 1 introduction to software engineering 1
Post on 19-Dec-2015
223 views
TRANSCRIPT
![Page 1: Chapter 1 Introduction to Software Engineering 1](https://reader035.vdocuments.site/reader035/viewer/2022062313/56649d2a5503460f949ff141/html5/thumbnails/1.jpg)
Chapter 1
Introduction to Software Engineering
1
![Page 2: Chapter 1 Introduction to Software Engineering 1](https://reader035.vdocuments.site/reader035/viewer/2022062313/56649d2a5503460f949ff141/html5/thumbnails/2.jpg)
Recommended Course Textbooks• R. S. Pressman (2005)
Software Engineering: A Practitioner’s Approach, 6th Edition, McGraw-Hill, 880 p.
• J. Greene, A. Stellman (2005)Applied Software Project Management,O’Reilly, 322 p.
• I. Sommerville (2004)Software Engineering, 7th Edition, Addison Wesley, 784 p.
• P. Jalote (2002)Software Project Management in Practice,Addison Wesley, 288 p.
2
![Page 3: Chapter 1 Introduction to Software Engineering 1](https://reader035.vdocuments.site/reader035/viewer/2022062313/56649d2a5503460f949ff141/html5/thumbnails/3.jpg)
Why Software Engineering?
• Software development is hard!• Important to distinguish “easy” systems (one
developer, one user, experimental use only) from “hard” systems (multiple developers, multiple users, products)
• Experience with “easy” systems is misleading– One person techniques do not scale up
• Analogy with bridge building:– Over a stream = easy, one person job– Over River Severn … ? (the techniques do not scale)
3
![Page 4: Chapter 1 Introduction to Software Engineering 1](https://reader035.vdocuments.site/reader035/viewer/2022062313/56649d2a5503460f949ff141/html5/thumbnails/4.jpg)
Why Software Engineering?
4
![Page 5: Chapter 1 Introduction to Software Engineering 1](https://reader035.vdocuments.site/reader035/viewer/2022062313/56649d2a5503460f949ff141/html5/thumbnails/5.jpg)
Why Software Engineering?
• The problem is complexity• Many sources, but size is key:– K Desktop Environment (KDE) contains 1.8 million
lines of code– UNIX contains 4 million lines of code– Windows Vista contains 50 million lines of code
Software engineering is about managing this complexity.
5
![Page 6: Chapter 1 Introduction to Software Engineering 1](https://reader035.vdocuments.site/reader035/viewer/2022062313/56649d2a5503460f949ff141/html5/thumbnails/6.jpg)
Software’s Dual Role
• Software is a product– Delivers computing potential– Produces, manages, acquires, modifies, displays, or
transmits information• Software is a vehicle for delivering a product– Supports or directly provides system functionality– Controls other programs (e.g., an operating system)– Effects communications (e.g., networking software)– Helps build other software (e.g., software tools)
6
![Page 7: Chapter 1 Introduction to Software Engineering 1](https://reader035.vdocuments.site/reader035/viewer/2022062313/56649d2a5503460f949ff141/html5/thumbnails/7.jpg)
Software Development Questions
• Why does it take so long to get software finished?
• Why are development costs so high?• Why can’t we find all errors before giving
software to customer?• Why do we spend so much time and effort
maintaining existing programs?• Why do we have difficulty in measuring progress
as software is being developed and maintained?7
![Page 8: Chapter 1 Introduction to Software Engineering 1](https://reader035.vdocuments.site/reader035/viewer/2022062313/56649d2a5503460f949ff141/html5/thumbnails/8.jpg)
What is software engineering?
Software engineering is an engineering discipline which is concerned with all aspects of software production
Software engineers should – adopt a systematic and organised approach to their work – use appropriate tools and techniques depending on
• the problem to be solved, • the development constraints and • the resources available
8
![Page 9: Chapter 1 Introduction to Software Engineering 1](https://reader035.vdocuments.site/reader035/viewer/2022062313/56649d2a5503460f949ff141/html5/thumbnails/9.jpg)
What is software engineering?
• At the first conference on software engineering in 1968, Fritz Bauer defined software engineering as “The establishment and use of sound engineering principles in order to obtain economically developed software that is reliable and works efficiently on real machines”.
• Stephen Schach defined the same as “A discipline whose aim is the production of quality software, software that is delivered on time, within budget, and that satisfies its requirements”.
• Both the definitions are popular and acceptable to majority. However, due to increase in cost of maintaining software, objective is now shifting to produce quality software that is maintainable, delivered on time, within budget, and also satisfies its requirements.
9
![Page 10: Chapter 1 Introduction to Software Engineering 1](https://reader035.vdocuments.site/reader035/viewer/2022062313/56649d2a5503460f949ff141/html5/thumbnails/10.jpg)
What is software?
• Computer programs and associated documentation
• Software =Program + Documentation +Operating Procedures
10
![Page 11: Chapter 1 Introduction to Software Engineering 1](https://reader035.vdocuments.site/reader035/viewer/2022062313/56649d2a5503460f949ff141/html5/thumbnails/11.jpg)
Documentation Manuals
• Documentation consists of different types of manuals are
11
![Page 12: Chapter 1 Introduction to Software Engineering 1](https://reader035.vdocuments.site/reader035/viewer/2022062313/56649d2a5503460f949ff141/html5/thumbnails/12.jpg)
Documentation Manuals
• Documentation consists of different types of manuals are
12
![Page 13: Chapter 1 Introduction to Software Engineering 1](https://reader035.vdocuments.site/reader035/viewer/2022062313/56649d2a5503460f949ff141/html5/thumbnails/13.jpg)
Software Product
• Software products may be developed for a particular customer or may be developed for a general market
• Software products may be– Generic - developed to be sold to a range of
different customers– Bespoke (custom) - developed for a single
customer according to their specification13
![Page 14: Chapter 1 Introduction to Software Engineering 1](https://reader035.vdocuments.site/reader035/viewer/2022062313/56649d2a5503460f949ff141/html5/thumbnails/14.jpg)
Software Product
• Software product is a product designated for delivery to the user
14
![Page 15: Chapter 1 Introduction to Software Engineering 1](https://reader035.vdocuments.site/reader035/viewer/2022062313/56649d2a5503460f949ff141/html5/thumbnails/15.jpg)
Software Characteristics
• Software is engineered• Software does not wear out.
Failure curve for hardware
15
![Page 16: Chapter 1 Introduction to Software Engineering 1](https://reader035.vdocuments.site/reader035/viewer/2022062313/56649d2a5503460f949ff141/html5/thumbnails/16.jpg)
Software Characteristics
• Software is not manufactured• Reusability of components• Software is flexible
16
![Page 17: Chapter 1 Introduction to Software Engineering 1](https://reader035.vdocuments.site/reader035/viewer/2022062313/56649d2a5503460f949ff141/html5/thumbnails/17.jpg)
Software Problems
• People that design and build software have to deal with many problems– Software is too expensive– Software takes too long to build– Software quality is low– Software is too complex to support and
maintain– Software does not age gracefully– Not enough highly-qualified people to design
and build software17
![Page 18: Chapter 1 Introduction to Software Engineering 1](https://reader035.vdocuments.site/reader035/viewer/2022062313/56649d2a5503460f949ff141/html5/thumbnails/18.jpg)
Software Cost
• Software projects often go over budget– Hurts the company and the customer
• Bad for the project– Many projects are cancelled– People may get fired or may quit
• Bad for the final product– Features are not implemented– Bad quality: not enough money to get it
right• Expensive in the long run
18
![Page 19: Chapter 1 Introduction to Software Engineering 1](https://reader035.vdocuments.site/reader035/viewer/2022062313/56649d2a5503460f949ff141/html5/thumbnails/19.jpg)
Software Time
• Software projects often take too long• Loss of revenue and market share– Both for the vendor and for the client– E.g.: baggage system at Denver airport
• Cost: $1 million per day
• Projects may become obsolete– Technology changes rapidly– Competing products already on the market
• Not enough time to implement all features and to ensure quality
19
![Page 20: Chapter 1 Introduction to Software Engineering 1](https://reader035.vdocuments.site/reader035/viewer/2022062313/56649d2a5503460f949ff141/html5/thumbnails/20.jpg)
Some Questions
• Studies of IT projects by the Standish Group (2000 and 2006)– 350+ IT managers, 8000+ applications
• What percentage of projects were– cancelled before being completed?– over budget and/or late?– completed on time and on budget?
• What was the cost/time overrun?
20
![Page 21: Chapter 1 Introduction to Software Engineering 1](https://reader035.vdocuments.site/reader035/viewer/2022062313/56649d2a5503460f949ff141/html5/thumbnails/21.jpg)
Success Rate
• Category 1: on time and on budget, with all initially specified features
• Category 2: over budget or over time, with fewer features than specified
• Category 3: cancelled
21
![Page 22: Chapter 1 Introduction to Software Engineering 1](https://reader035.vdocuments.site/reader035/viewer/2022062313/56649d2a5503460f949ff141/html5/thumbnails/22.jpg)
Overruns and Deficiencies
• Cost and time overruns– Averages for category 2 and category 3
• Cost overruns: 189% of original estimate• Time overruns: 222% of original estimate• Feature deficiencies: only 61% of the
originally specified features were implemented
• Average for category 2
22
![Page 23: Chapter 1 Introduction to Software Engineering 1](https://reader035.vdocuments.site/reader035/viewer/2022062313/56649d2a5503460f949ff141/html5/thumbnails/23.jpg)
Some Reasons for Failure
• Lack of user involvement• Incomplete requirements and specs• Changing requirements and specs• Lack of executive support (politics)• Lack of planning and management• Inadequate resources and time– Death-march projects
• Technology incompetence
23
![Page 24: Chapter 1 Introduction to Software Engineering 1](https://reader035.vdocuments.site/reader035/viewer/2022062313/56649d2a5503460f949ff141/html5/thumbnails/24.jpg)
Software Quality
• Software defects result in failures– Example 1: Windows crashes while you play a
game at home– Example 2: The software that controls a
nuclear reactor crashes• Direct loss of life and money– Millions of dollars
• Indirect loss: missed opportunities– e.g. online purchases are down for a day
• Loss of credibility, bad publicity
24
![Page 25: Chapter 1 Introduction to Software Engineering 1](https://reader035.vdocuments.site/reader035/viewer/2022062313/56649d2a5503460f949ff141/html5/thumbnails/25.jpg)
Software failures
• Therac-25 (1985-1987): six people overexposed during treatments for cancer
• Taurus (1993): the planned automatic transaction settlement system for London Stock Exchange cancelled after five years of development
• Ariane 5 (1996): roket exploded soon after its launch due error conversion (16-bit floating point into 16-bit signed integer)
• The Mars Climate Orbiter assumed to be lost by NASA officials (1999): different measurement systems (Imperial and metric)
25
![Page 26: Chapter 1 Introduction to Software Engineering 1](https://reader035.vdocuments.site/reader035/viewer/2022062313/56649d2a5503460f949ff141/html5/thumbnails/26.jpg)
Example: Ariane 5
• Ariane 5 rocket• Built by the European Space Agency• First launch: June 1996• Crashed 40 seconds after launch• Cost: $500 million• No people on board• Problem: software failure
26
![Page 27: Chapter 1 Introduction to Software Engineering 1](https://reader035.vdocuments.site/reader035/viewer/2022062313/56649d2a5503460f949ff141/html5/thumbnails/27.jpg)
What Happened?
• Overflow when velocity was converted from 64-bit floating point to 16-bit signed integer
• The exception was not caught– Inertial Reference System failed
• Backup system failed for the same reason
– Rocket went off course– Self-destruct module (correctly) activated
• The code was OK for Ariane 4– Same software, different environment
27
![Page 28: Chapter 1 Introduction to Software Engineering 1](https://reader035.vdocuments.site/reader035/viewer/2022062313/56649d2a5503460f949ff141/html5/thumbnails/28.jpg)
Software Applications
28
![Page 29: Chapter 1 Introduction to Software Engineering 1](https://reader035.vdocuments.site/reader035/viewer/2022062313/56649d2a5503460f949ff141/html5/thumbnails/29.jpg)
What is a software process?
• SP is a set of activities whose goal is the development or evolution of software
• Fundamental activities in all software processes are:– Specification - what the system should do
and its development constraints– Development - production of the software system
(design and implementation) – Validation - checking that the software is what the
customer wants– Evolution - changing the software in response to changing
demands
29
![Page 30: Chapter 1 Introduction to Software Engineering 1](https://reader035.vdocuments.site/reader035/viewer/2022062313/56649d2a5503460f949ff141/html5/thumbnails/30.jpg)
What is a software process model?
SPM is a simplified representation of a software process, presented from a specific perspective
• Examples of process perspectives: Workflow perspective represents inputs, outputs and dependencies Data-flow perspective represents data transformation activities Role/action perspective represents the roles/activities of the
people involved in software process • Generic process models
– Waterfall– Evolutionary development– Formal transformation– Integration from reusable components
30
![Page 31: Chapter 1 Introduction to Software Engineering 1](https://reader035.vdocuments.site/reader035/viewer/2022062313/56649d2a5503460f949ff141/html5/thumbnails/31.jpg)
What are the costs of software engineering?
• Roughly 60% of costs are development costs, 40% are testing costs. For custom software, evolution costs often exceed development costs
• Costs vary depending on the type of system being developed and the requirements of system attributes such as performance and system reliability
• Distribution of costs depends on the development model that is used
31
![Page 32: Chapter 1 Introduction to Software Engineering 1](https://reader035.vdocuments.site/reader035/viewer/2022062313/56649d2a5503460f949ff141/html5/thumbnails/32.jpg)
What is CASE ? (Computer-Aided Software Engineering)
32
Upper-CASEUpper-CASE Tools to support the early process Tools to support the early process
activities of requirements and designactivities of requirements and design Lower-CASELower-CASE
Tools to support later activities such Tools to support later activities such as programming, debugging and as programming, debugging and testingtesting
Software systems which are intended to provide automated support for software process activities, such as requirements analysis, system modelling, debugging and testing
![Page 33: Chapter 1 Introduction to Software Engineering 1](https://reader035.vdocuments.site/reader035/viewer/2022062313/56649d2a5503460f949ff141/html5/thumbnails/33.jpg)
What are the attributes of good software?
33
MaintainabilityMaintainability Software must evolve to meet changing needsSoftware must evolve to meet changing needs
DependabilityDependability Software must be trustworthySoftware must be trustworthy
EfficiencyEfficiency Software should not make wasteful use of system resourcesSoftware should not make wasteful use of system resources
UsabilityUsability Software must be usable by the users for which it was designedSoftware must be usable by the users for which it was designed
The software should deliver the required functionality and performance to the user and should be maintainable, dependable and usable
![Page 34: Chapter 1 Introduction to Software Engineering 1](https://reader035.vdocuments.site/reader035/viewer/2022062313/56649d2a5503460f949ff141/html5/thumbnails/34.jpg)
What are the key challengesfacing software engineering?
Software engineering in the 21st century faces three key challenges:
• Legacy systems– Old, valuable systems must be maintained and
updated• Heterogeneity– Systems are distributed and include a mix
of hardware and software• Delivery– There is increasing pressure
for faster delivery of software
34
![Page 35: Chapter 1 Introduction to Software Engineering 1](https://reader035.vdocuments.site/reader035/viewer/2022062313/56649d2a5503460f949ff141/html5/thumbnails/35.jpg)
Legacy Software
• Were developed decades ago and have been continually modified to meet changes in business requirements and computing platforms.
• Why must it change?– software must be adapted to meet the needs of new computing
environments or technology.– software must be enhanced to implement new business
requirements.– software must be extended to make it interoperable with other more
modern systems or databases.– software must be re-architected to make it viable within a network
environment.35
![Page 36: Chapter 1 Introduction to Software Engineering 1](https://reader035.vdocuments.site/reader035/viewer/2022062313/56649d2a5503460f949ff141/html5/thumbnails/36.jpg)
Software Evolution• The Law of Continuing Change (1974): E-type systems must be continually adapted else they become
progressively less satisfactory.• The Law of Increasing Complexity (1974): As an E-type system evolves its complexity increases unless work
is done to maintain or reduce it.• The Law of Self Regulation (1974): The E-type system evolution process is self-regulating with distribution
of product and process measures close to normal.• The Law of Conservation of Organizational Stability (1980): The average effective global activity rate in an
evolving E-type system is invariant over product lifetime.• The Law of Conservation of Familiarity (1980): As an E-type system evolves all associated with it,
developers, sales personnel, users, for example, must maintain mastery of its content and behavior to achieve satisfactory evolution.
• The Law of Continuing Growth (1980): The functional content of E-type systems must be continually increased to maintain user satisfaction over their lifetime.
• The Law of Declining Quality (1996): The quality of E-type systems will appear to be declining unless they are rigorously maintained and adapted to operational environment changes.
• The Feedback System Law (1996): E-type evolution processes constitute multi-level, multi-loop, multi-agent feedback systems and must be treated as such to achieve significant improvement over any reasonable base.
36
Source: Lehman, M., et al, “Metrics and Laws of Software Evolution—The Nineties View,” Proceedings of the 4th International Software Metrics Symposium (METRICS '97), IEEE, 1997, can be downloaded from: http://www.ece.utexas.edu/~perry/work/papers/feast1.pdf
![Page 37: Chapter 1 Introduction to Software Engineering 1](https://reader035.vdocuments.site/reader035/viewer/2022062313/56649d2a5503460f949ff141/html5/thumbnails/37.jpg)
Software Myths
• Affect managers, customers (and other non-technical stakeholders) and developers
• Are believable because they often have elements of truth, but …
• Invariably lead to bad decisions, therefore …
• Insist on reality as you navigate your way through software engineering
37
![Page 38: Chapter 1 Introduction to Software Engineering 1](https://reader035.vdocuments.site/reader035/viewer/2022062313/56649d2a5503460f949ff141/html5/thumbnails/38.jpg)
Manager Myths
• Management may be confident about good standards and clear procedures of the company.– But the taste of any food item is in the eating; not in the Recipe!
• Company has latest computers and state-of-the- art software tools, so we shouldn’t worry about the quality of the product.– The infrastructure is only one of the several factors that determine the quality
of the product!• Addition of more software specialists, those with higher skills and longer
experience may bring the schedule back on the track!– Unfortunately, that may further delay the schedule!
• Software is easy to change– The reality is totally different.
• Computers provide greater reliability than the devices they replace– This is not always true.
38
![Page 39: Chapter 1 Introduction to Software Engineering 1](https://reader035.vdocuments.site/reader035/viewer/2022062313/56649d2a5503460f949ff141/html5/thumbnails/39.jpg)
Customer Myths
• A general statement of objectives is sufficient to get started with the development of software. Missing/vague requirements can easily be incorporated/detailed out as they get concretized.– If we do so, we are heading towards a disaster.
• Software with more features is better software• Software can work right the first time– Both are only myths!
39
![Page 40: Chapter 1 Introduction to Software Engineering 1](https://reader035.vdocuments.site/reader035/viewer/2022062313/56649d2a5503460f949ff141/html5/thumbnails/40.jpg)
Developer Myths
• Once the software is demonstrated, the job is done.– Usually, the problems just begin!
• Software quality can not be assessed before testing.– However, quality assessment techniques should be used
through out the software development life cycle.• The only deliverable for a software development project is
the tested code.– Tested code is only one of the deliverable!
• Aim is to develop working programs– Those days are over. Now objective is to develop good quality
maintainable programs!
40