Introduction Foundations of Software Engineering - UPTlabs.cs.upt.ro/~oose/uploads/FSE/fis2009-chapter1.pdf · Foundations of Software Engineering ... Co-author of the Object-Oriented

Foundations of Software Engineering

Dr. Radu Marinescu


1


Dr. Radu Marinescu 2

Introduction



I, Me and Myself :-)

! Associate Professor at “Politehnica” University of Timi!oara! Department of Computer Science

! lectures on “Software Engineering”, “Good Object Oriented Design”, “Quality Assurance & Software Evolution”

! Head of the LOOSE Research Group

! Researcher since 1997! on Metrics, OO Design, Software Evolution, Reengineering,

! over 30 publications in main international conferences

! PC member in main IEEE/ACM conferences on software maintenance and evolution (ICSM, ICPC, MODELS/UML etc)

! member of the European Network of Excellence in Software Evolution

! Software (Tool) Developer! autor/co-author of: TableGen, MEMORIA, iPlasma/Insider, inCode



Some Achievements

! Co-author of the Object-Oriented Metrics in Practice book! Springer, August 2006

! IBM Eclipse Innovation Award (2006)

! Industrial Consultancy for...


Dr. Radu Marinescu

Contact

! email: [email protected]

! phone: 404058

! office: ASPC, P11

5


Dr. Radu Marinescu

Randy Pausch Last Lecture

6


Dr. Radu Marinescu

! Monday

! 08 ; 10 : Petru Mihancea

! Tuesday ! 10 (Info) ; 12 ; 14 : Petru Mihancea

! 16 ; 18 : Radu Fericean

! Thursday

! 10 ; 12 ; 14 (Info) : Georgiana Macariu

! 16 (Info) ; 18 (Info) : Dr. Adrian Trifu

! Friday

! 8 ; 10 ; 12 : Dr. Adrian Trifu

! 14 : Georgiana Macariu

Labs in room B426

7


Dr. Radu Marinescu

http://loose.upt.ro/~oose

! Vital Source of Information! Lectures

" this lecture and other lectures on Software Engineering topics

! Labs

! Exam Results

! Resources

! oose07

8


Dr. Radu Marinescu

Bibliography...

9


Dr. Radu Marinescu

! 3 h

! asimilare !i în"elegere real# de cuno!tin"e !NU reproducere mecanic! de text!

! surse multiple de informa"ie! citi"i mult !i forma"i-v# o p#rere!

! teorie + probleme! promovabile doar atomic

! un num#r mare de subiecte mici

! la probleme la fel

! M!rire examen scris+oral ! oral din toat# materia pentru marire de la 8 la 10

Examen SCRIS (+ oral pentru mariri de la 8 la 10)

10



Goals, Roles and Myths of Software Engineering


Dr. Radu Marinescu

Joys of Programming [Brooks,1995]

! Joy of creating things

!and pleasure of making useful things for the others

! Fascination of fashioning complex puzzle-like objects

! Delight of working in a highly tractable (flexible) medium! Slightly removed from the realm of “pure ideas”

! Easy to polish and rework

! It’s fun because it gratifies creative longings

! Joy of always learning

12


Dr. Radu Marinescu

Woes of Programming [Brooks,1995]

! We must perform perfectly

! Dependency upon others ! Including dependencies on other people’s imperfections

! Study and fix things that in an ideal world would be perfect

! Creativity is not the whole story! Designing grand concepts is fun, finding little bugs is just work :-(

! Products are oftentimes obsolete upon (or before) completion! Laws of Software Evolution

13


Dr. Radu Marinescu

Software Crisis in the 60’s

! Rapid increase of computer power and complexity of

problems to be solved

! Difficulty to write programs that are:! Correct

! Understandable

! Verifiable

14


Dr. Radu Marinescu

Root of Software Crisis

! Complexity! Orders of magnitude larger and more complex than previously

developed software

! Expectations! Hardware prices were going down, prices for software were

increasing dramatically

! Change! Need to maintain and evolve programs

15


Dr. Radu Marinescu

In other words…

"The major cause of the software crisis is that

the machines have become several orders of magnitude more powerful!

To put it quite bluntly:

as long as there were no machines,

programming was no problem at all;

when we had a few weak computers,

programming became a mild problem,

and now we have gigantic computers,

thus programming has become an equally gigantic problem."

E.W.Dijkstra, 1972

(The Humble Programmger, ACM Turing Award Lecture)

16


Dr. Radu Marinescu

1st Conference on Software Engineering (1968)

17



Small vs. Large Projects

! Small projects can be understood and implemented by one

person! For 1 person, by 1 person

! Large projects require division of labor, integration,

management! For many people, by many people

! “Real” systems are more than just code…

! Let’s see…


Dr. Radu Marinescu

Program vs. Software [Brooks,1995]

Program

ProgrammingSystem

(Interfaces,System Integration)

ProgrammingProduct

(Generalization,Testing,

Documentation,Maintenance)

x3

x3

ProgrammingSystemsProduct

19


Dr. Radu Marinescu

The Tar Pit of Software [Brooks,1995]

20


Dr. Radu Marinescu

The Challenge

21

“The challenge and the mission are to find real solutions to real problems,

on actual schedules with available resources.”

F.P.Brooks, 1995


Dr. Radu Marinescu

What do we need to learn ?

! Processes! how to manage long-term development/deployment of software

" what are the phase and what’s the flow?

! Techniques! how should we approach each phase of the process?

! Tools! how to automate as much as possible of the process?

22


Dr. Radu Marinescu

FAQs about software engineering

1. What is software?

2. What is software engineering?

3. Software engineering vs. computer science?

4. What are the costs?

5. What is CASE (Computer-Aided Software Engineering)

6. What is good software?

23


Dr. Radu Marinescu

Q1: What is Software?

24


Dr. Radu Marinescu

What is software?

! Computer programs and associated documentation! e.g. requirements, design models and user manuals.

! Software products may be!Generic - developed to be sold to a range of different customers

e.g. PC software such as Excel or Word.

!Custom - developed for a single customer according to their specification.

! New software can be created by !developing new programs,

!configuring generic software systems or

! reusing existing software.

25


Dr. Radu Marinescu

Characteristics of Software

1. Software is engineered, not manufactured

2. Software does not “wear out”... but it deteriorates

3. Most software continues to be custom built

26


Dr. Radu Marinescu

1. Software is engineered, not manufactured

! Engineered = a human creative process! analysis, design, construction, testing

! Hardware after being engineered is translated into a

physical form (manufacturing)! e.g. chips, circuit boards etc.

! Software is only about engineering! the manufacturing phase does not introduce quality problems

! ...or easily correctable problems

27

Costs of software are strictly in engineering.Software projects can’t be managed as manufacturing projects

CHAPTER 1 THE PRODUCT

ity is achieved through good design, but the manufacturing phase for hardware canintroduce quality problems that are nonexistent (or easily corrected) for software.Both activities are dependent on people, but the relationship between people appliedand work accomplished is entirely different (see Chapter 7). Both activities requirethe construction of a "product" but the approaches are different.

Software costs are concentrated in engineering. This means that software proj-ects cannot be managed as if they were manufacturing projects.

2. Software doesn't "wear out."

Figure 1.1 depicts failure rate as a function of time for hardware. The relationship,often called the "bathtub curve," indicates that hardware exhibits relatively high fail-ure rates early in its life (these failures are often attributable to design or manufac-turing defects); defects are corrected and the failure rate drops to a steady-state level(ideally, quite low) for some period of time. As time passes, however, the failure raterises again as hardware components suffer from the cumulative affects of dust, vibra-tion, abuse, temperature extremes, and many other environmental maladies. Statedsimply, the hardware begins to wear out.

Software is not susceptible to the environmental maladies that cause hardware towear out. In theory, therefore, the failure rate curve for software should take the form ofthe “idealized curve” shown in Figure 1.2. Undiscovered defects will cause high failurerates early in the life of a program. However, these are corrected (ideally, without intro-ducing other errors) and the curve flattens as shown.The idealized curve is a gross over-simplification of actual failure models (see Chapter 8 for more information) for software.However, the implication is clear—software doesn't wear out. But it does deteriorate!

This seeming contradiction can best be explained by considering the “actual curve”shown in Figure 1.2. During its life, software will undergo change (maintenance). As

7

“Wear out”“Infantmortality”

TimeFa

ilure

rate

FIGURE 1.1Failure curvefor hardware

Software doesn’t wearout, but it doesdeteriorate.


Dr. Radu Marinescu

2. Hardware “Wears Out”. Software Doesn’t!

28

from R.S.Pressman, 2005

PART ONE THE PRODUCT AND THE PROCESS8

changes are made, it is likely that some new defects will be introduced, causing thefailure rate curve to spike as shown in Figure 1.2. Before the curve can return to theoriginal steady-state failure rate, another change is requested, causing the curve tospike again. Slowly, the minimum failure rate level begins to rise—the software isdeteriorating due to change.

Another aspect of wear illustrates the difference between hardware and software.When a hardware component wears out, it is replaced by a spare part. There are nosoftware spare parts. Every software failure indicates an error in design or in theprocess through which design was translated into machine executable code. There-fore, software maintenance involves considerably more complexity than hardwaremaintenance.

3. Although the industry is moving toward component-based assembly, mostsoftware continues to be custom built.

Consider the manner in which the control hardware for a computer-based productis designed and built. The design engineer draws a simple schematic of the digitalcircuitry, does some fundamental analysis to assure that proper function will beachieved, and then goes to the shelf where catalogs of digital components exist. Eachintegrated circuit (called an IC or a chip) has a part number, a defined and validatedfunction, a well-defined interface, and a standard set of integration guidelines. Aftereach component is selected, it can be ordered off the shelf.

As an engineering discipline evolves, a collection of standard design componentsis created. Standard screws and off-the-shelf integrated circuits are only two of thou-sands of standard components that are used by mechanical and electrical engineersas they design new systems. The reusable components have been created so that theengineer can concentrate on the truly innovative elements of a design, that is, the

FIGURE 1.2Idealized andactual failurecurves forsoftware

Increased failurerate due to side

effects

Time

Failu

re ra

te

Change

Actual curve

Idealized curve

Most softwarecontinues to be custom built.

Software engineeringmethods strive toreduce the magnitudeof the spikes and theslope of the actualcurve in Figure 1.2.


Dr. Radu Marinescu

Ideal Failure Curve for Software

29


PART ONE THE PRODUCT AND THE PROCESS8

changes are made, it is likely that some new defects will be introduced, causing thefailure rate curve to spike as shown in Figure 1.2. Before the curve can return to theoriginal steady-state failure rate, another change is requested, causing the curve tospike again. Slowly, the minimum failure rate level begins to rise—the software isdeteriorating due to change.

Another aspect of wear illustrates the difference between hardware and software.When a hardware component wears out, it is replaced by a spare part. There are nosoftware spare parts. Every software failure indicates an error in design or in theprocess through which design was translated into machine executable code. There-fore, software maintenance involves considerably more complexity than hardwaremaintenance.

3. Although the industry is moving toward component-based assembly, mostsoftware continues to be custom built.

Consider the manner in which the control hardware for a computer-based productis designed and built. The design engineer draws a simple schematic of the digitalcircuitry, does some fundamental analysis to assure that proper function will beachieved, and then goes to the shelf where catalogs of digital components exist. Eachintegrated circuit (called an IC or a chip) has a part number, a defined and validatedfunction, a well-defined interface, and a standard set of integration guidelines. Aftereach component is selected, it can be ordered off the shelf.

As an engineering discipline evolves, a collection of standard design componentsis created. Standard screws and off-the-shelf integrated circuits are only two of thou-sands of standard components that are used by mechanical and electrical engineersas they design new systems. The reusable components have been created so that theengineer can concentrate on the truly innovative elements of a design, that is, the

FIGURE 1.2Idealized andactual failurecurves forsoftware

Increased failurerate due to side

effects

Time

Failu

re ra

te

Change

Actual curve

Idealized curve

Most softwarecontinues to be custom built.

Software engineeringmethods strive toreduce the magnitudeof the spikes and theslope of the actualcurve in Figure 1.2.


Dr. Radu Marinescu

Actual Failure Curve for Software

30


Software does not “wear out”! But it does deteriorate!The main cause for this phenomenon is repeated change



Why must it change?

! Enhance! to implement new business requirements.

! Extend & Adapt! make it interoperable with other more modern systems

! to meet the needs of new computing environments



Laws of Software Evolution! The Law of Continuing Change (1974): Systems must be continually

adapted else they become progressively less satisfactory.

! The Law of Continuing Growth (1980): The functional content of systems

must be continually increased to maintain user satisfaction over their lifetime.

! The Law of Increasing Complexity (1974): As a system evolves its

complexity increases unless work is done to maintain or reduce it.

! The Law of Declining Quality (1996): The quality of systems will appear to

be declining, unless they are rigorously maintained and adapted to

operational environment changes.

! The Law of Conservation of Organizational Stability (1980): The average

effective global activity rate in an evolving system is invariant over product

lifetime.

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


Dr. Radu Marinescu

Software has no “sparse parts”

33

! When hardware components wear out, they can be

replaced by sparse parts.

! ... but there are no sparse parts for software! failures indicate design errors or in the process of translating design

into machine executable code.

Software maintenance involves considerably more complexity than hardware maintenance!


Dr. Radu Marinescu

3. Software is still custom- not component-built

! In each engineering discipline standard design components

are created! e.g. in hardware: integrated circuits

! In software we need more than algorithmic libraries! reuse both algorithms and data structures

! e.g. GUIs

! Example of reusing in large: Frameworks! inversion of control: “Hollywood Principle”

34


Dr. Radu Marinescu

Q2: What is Software Engineering?

35


Dr. Radu Marinescu

What is software engineering?

! Software engineering is an engineering discipline that is concerned

with all aspects of software production.

! Adequate usage of appropriate tools and techniques depending on! the problem to be solved,

! development constraints

! resources available.

! Software engineering is concerned with methods, techniques and

tools for professional software development.

36


Dr. Radu Marinescu

Q3: Software engineering vs. computer science

! Computer Science is concerned with theory and

fundamentals

! Software Engineering is concerned with the practicalities

of developing and delivering useful software.

! Computer science theories are still insufficient to act as a

complete underpinning for software engineering ! unlike e.g. physics and electrical engineering.

37


Dr. Radu Marinescu

Q4: What are the Costs of Software Engineering?

38


Dr. Radu Marinescu

! Software costs often dominate computer system costs.

! Software costs more to maintain than it does to develop.! For systems with a long life, maintenance costs may be several

times development costs.

! Software engineering is concerned with cost-effective

software development.

Costs of software engineering

39



Main Cost is not coding!

! System Tests are the strongest sequential constraint

Brook’s Scheduling Rule: 1/3 Planning

1/6 Coding

1/4 Component Test

1/4 System Test

! Fraction devoted to planning is larger

! Half of schedule goes to testing

Not enough testing times is disastrous because bad news come late!



“In examining conventionally scheduled projects,

I have found that few allowed

one-half of the projected schedule for testing,

but that most did indeed

spend half of the actual schedule for that purpose.”

F.P.Brooks


Dr. Radu Marinescu

Q5: What is CASE? (Computer-Aided Software Engineering)

! Software systems that are intended to provide automated support for software process activities.

!often used for method support.

! Upper-CASE!Tools to support the early process activities of requirements

and design;

! Lower-CASE!Tools to support later activities such as programming,

debugging and testing.

42


Dr. Radu Marinescu

Q6: What makes GOOD software?

! Acceptability!accepted by the users for which it was designed.

!understandable, usable and compatible with other systems.

! Dependability!Software must be trustworthy;

! Efficiency!Software should not make wasteful use of system resources;

! Maintainability!Software must evolve to meet changing needs;

43


Dr. Radu Marinescu

Key challenges facing software engineering

! Legacy! Challenge of maintaining and updating this software

! Avoid “software aging” [Parnas]

! ...and “software entropy”[Lehman]

! Heterogeneity! Cope with heterogeneous platforms and execution environments;

! Delivery! Developing techniques that lead to faster delivery of software;

! Trust! Techniques that prove that software can be trusted by its users.

44


Dr. Radu Marinescu

Software Myths

45


Dr. Radu Marinescu

Software Myths [Pressman, 2005]

Myths are not heroic legends :) ... they are propagated misinformation!

! Myths are dangerous because:

1. they appear reasonable and intuitive

2. they are hard to change!

! Each involved site has its myths:! Management myths

! Customer myths

! Developer myths

46


Dr. Radu Marinescu

Management Myths

I. We have books, standards and procedures that guarantee good

software

! Are they up-to-date? Are they used? Are they complete?

II. We buy high-end computers and most expensive CASE tools

! Are these used efficiently? Are these customized for specific needs?

III.Outsourcing will release us from software engineering problems

! Managing a project externally is harder than doing it internally

IV.If project gets late we will add more programmers and catch up

! F.P. Brooks calls this the “mythical man-month”: Adding people to a late project, makes the project even later

47



Adding more programmers to a late project...

! Project is Planned for 3 people x 4 months

! If there is no time (e.g. we have to finish it in 2 months)…

What do we do??

! ADD MANPOWER! E.g. employ 3 more people

! Believing that 3 people x 4 months = 6 people x 2 months

WRONG!



Types of Tasks

Perfectly Partitionable Task! No inter-communication required

! E.g. reaping wheat

Totally Unpartitionable Task! Sequential constraints

! More effort no effect on schedule

! E.g. bearing a child



Types of Tasks (2)

Task Requiring Communication! Effort of communication must be added

to the amount of work to be done

! Poorer than even trade of men for months

Task with Complex Interrelationships

! Communication may fully counteract the division of the original task



Communication

! Training! Technological, goals of the effort, overall strategy plan of work

! Intercommunication! For N people involved: N*(N-1)/2

! E.g. It is 6 x in a team of 4 people compared to a team of 2 people



Brook’s Law

Corollaries

Nr. of months of a project depends on its sequential constraints

Maximum nr. of people depends on the nr. of independent subtasks

Adding manpower to a late software project makes it later


Dr. Radu Marinescu

Customer Myths

I. Just sketching the requirements is enough to start building

software

II. Requirements can permanently change at a low cost because

software is flexible

53



Dr. Radu Marinescu

Developer Myths

I. Once we write a program and get it to work, our job is done

! “the sooner you begin ‘writing code’ the longer it’ll take to get done”

II. The only deliverable work product is the working program

! program is only a part of a working configuration, which also includes documentation

III.Software engineering will make use create voluminous and

unnecessary documentation, which slows us down

! Pressman: “SWE is not about creating documents. It’s about creating quality. Better quality leads to reduced work.”

54

Documents

Introduction Foundations of Software Engineering - UPTlabs.cs.upt.ro/~oose/uploads/FSE/fis2009-chapter1.pdf · Foundations of Software Engineering ... Co-author of the Object-Oriented