slide 1.1 chapter 1 introduction to software engineering
TRANSCRIPT
Slide 1.1
CHAPTER 1
INTRODUCTION TO SOFTWARE ENGINEERING
Slide 1.2
Outline
Historical aspects Economic aspects Maintenance aspects Specification and design aspects Team programming aspects The object-oriented paradigm Terminology
Slide 1.3
Scope of Software Engineering
Historical Aspects– A NATO study group in 1967 coined the term
software engineering – “building software is similar to other engineering tasks”
– Endorsed by the 1968 NATO Conference in Garmisch, Germany
– Aim: to solve the “Software Crisis”– Software is delivered
» Late» Over budget» Low quality with lots of faults
– Software crisis is still present over 35 years later!
Slide 1.4
Scope of Software Engineering (contd)
Why cannot bridge-building techniques be used to build operating systems? – Attitude to collapse
» Bridge collapse - redesigned and rebuilt from scratch» Operating system crash – reboot!
– Imperfect engineering» Bridges are assumed to be perfectly engineered» OSs are assumed to be imperfectly engineered
– Complexity is growing faster than we can master– Maintenance
» Bridge maintenance – painting, repairing cracks, resurfacing the road
» Software maintenance – porting to new hardware, adding more functions, re-write some parts, etc.
Slide 1.5
Conclusion
Software engineering is a discipline whose aim is the production of fault-free software that satisfies the user’s needs and is delivered on time within budget
Software Engineering is not “Engineering” – Not as the same way viewed in other engineering
disciplines
Slide 1.6
Economic Aspects
Computer scientists investigate a variety of ways to produce software but software engineers are interested in economically viable techniques
Coding method CMnew is 10% faster than currently used method CMold. Should it be used?– Common sense answer
» Of course!
– Software Engineering answer must consider» the cost of introducing CMnew into an organization
» the effect of CMnew on maintenance
Slide 1.7
Maintenance Aspects
Software Life Cycle– The way we produce software, including
» The life-cycle model» The individuals» CASE tools
Until the end of 1970s, most organizations were producing software using the Waterfall Model
Slide 1.8
Life-cycle Model
1. Requirements phase- Client’s requirements are elicited
2. Specification phase- what is the software supposed to do?
3. Design phase- how the software does it
4. Implementation phase – coding and testing the components
5. Integration phase- combined and tested
6. Maintenance phase- Corrective (repair)- Enhancement (update)
7. Retirement– Removed from service
Slide 1.9
Approximate Relative Cost of Each Phase
1976–1981 data Maintenance constitutes 67% of total cost
Slide 1.10
Comparative Relative Cost of Each Phase
Slide 1.11
Good and Bad Software
Good software is maintained—bad software is discarded
Different types of maintenance– Corrective maintenance [about 20%]– Enhancement
» Corrective (Perfective) maintenance [about 60%]» Enhancement (Adaptive) maintenance [about 20%]
Effect of CMnew on maintenance
Slide 1.12
Specification and Design Aspects
60 to 70 percent of faults are specification and design faults [Boehm, 1979]
Data of Kelly, Sherif, and Hops [1992]– 1.9 faults per page of specification– 0.9 faults per page of design– 0.3 faults per page of code
Slide 1.13
Cost to Detect and Correct a Fault
Slide 1.14
Specification and Design Aspects (contd)
Data of Bhandari et al. [1994] Faults at end of the design phase of the
new version of the product– 13% of faults from previous version of product– 16% of faults in new specifications– 71% of faults in new design
Faults must be found and corrected early in the development stage, otherwise it will cost a lot!
Slide 1.15
Team Programming Aspects
Hardware is cheap– performance-price factor = time to perform 1 million
additions x cost of CPU and main memory – We can build products that are too large to be written
by one person in the available time
Large product must be developed by a team But team programming leads to
– Interface problems– Communication problems
Good team organization and management is essential
Slide 1.16
The Object-Oriented Paradigm
Structured paradigm had great successes initially– Structured systems analysis, data flow analysis,
structured programming, structured testing– It started to fail with larger products (> 50,000 LOC)
Maintenance problems (today, up to 80% of effort)
Reason: structured methods are – Action oriented (finite state machines, data flow
diagrams); or – Data oriented (entity-relationship diagrams, Jackson’s
method);– But not both
Slide 1.17
The Object-Oriented Paradigm (contd)
Both data and actions are of equal importance Object:
– Software component that incorporates both data and the actions that are performed on that data
Example:– Bank account
» Data: account balance
» Actions: deposit, withdraw, determine balance
Slide 1.18
Structured versus Object-Oriented Paradigm
Slide 1.19
Key Aspects of Object-Oriented Solution
Conceptual independence– Encapsulation
Physical independence – Information hiding
Impact on development– Physical counterpart
Impact on maintenance– Independence effects: only changes that need be
made are within the object itself Increased reusabilty
– Can be utilized in the future products
Slide 1.20
Responsibility-Driven Design
Also called “Design by Contract” Send flowers to your aunt in Iowa City
– Call 1-800-FLOWERS– Where is 1-800-FLOWERS?– Which Iowa City florist does the delivery?– Information hiding
Object-oriented paradigm– “Send a message to a method [action] of an object“
Slide 1.21
Transition From Analysis to Design
Structured paradigm:– A sharp transition between analysis (what) and design
(how) Object-oriented paradigm:
– Objects enter from very beginning
Slide 1.22
Analysis/Design “Hump”
Systems analysis– Determine what has to be done
Design– Determine how to do it– Architectural design—determine modules– Detailed design—design each module
Slide 1.23
Removing the “Hump”
Object-oriented analysis– Determine what has to be done– Determine the objects
Object-oriented design– Determine how to do it– Design the objects
Slide 1.24
In More Detail
Objects enter here
Slide 1.25
Warning
Do not use the object-paradigm to enhance a product developed using the structured paradigm– Water and oil do not mix
Exception: if the new part is totally disjoint– Example: adding a GUI (graphical user interface)
Slide 1.26
Terminology
Program, system Software: program + documentation Product
– a nontrivial piece of software– The end result of software production
Software production: development + maintenance Methodology, paradigm: a collection of techniques for
carrying out the software production Bug
– “A bug crept into the code”
instead of
– “I made an error”
Slide 1.27
Object-Oriented Terminology
Data component of an object– State variable– Instance variable (Java)– Field (C++)– Attribute (generic)
Action component of an object– Member function (C++)– Method (generic)
Slide 1.28
Object-Oriented Terminology (contd)
C++: A member is either an– Attribute (“field”), or a– Method (“member function”)
Java: A field is either an– Attribute (“instance variable”), or a– Method
Read Chapter 1 Do Problems 1.1-1.11