Software Engineering - Introduction - Fernando Brito e Abreu - - PDF document

1

Software Engineering

• Introduction -

Fernando Brito e Abreu (fba@di.fct.unl.pt) Universidade Nova de Lisboa (http://www.unl.pt)

QUASAR Research Group (http://ctp.di.fct.unl.pt/QUASAR)

Software Engineering / Fernando Brito e Abreu 2 7-Jun-05

Summary

• Motivation

Motivation

Course structure

Theory classes Lab classes

Evaluation Bibliography

2

Software Engineering / Fernando Brito e Abreu 3 7-Jun-05

Summary

• Motivation

Motivation

• Course structure

Course structure Course structure

• Theory classes

Theory classes Theory classes

• Lab classes

Lab classes Lab classes

• Evaluation

Evaluation Evaluation

• Bibliography

Bibliography Bibliography

Software Engineering / Fernando Brito e Abreu 4 7-Jun-05

Crisis? What Crisis?

After 5 decades the software community is

still unable to consistently produce reliable software on time and within budget that completely satisfies customers

Robert L. Glass: Software Runaways: Monumental Software Disasters, Prentice Hall PTR, 1998, ISBN: 0-13-673443-X Robert L. Glass : Computing Calamities - Lessons Learned From Products, Projects and Companies That Failed, Prentice Hall PTR, 1988, ISBN: 0-13-0828629

3

Software Engineering / Fernando Brito e Abreu 5 7-Jun-05

Are Professors to Blame?

“Real world” - Programming in the large

large teams, large overheads, deliverables often late,

• ver budget

no assessment by peers ⇒ quality doesn’t pay!

Universities - Programming in the small

small teams, small overheads, schedules are met,

budget is not a constraint

assessment by “graduate peers” ⇒ quality pays!

We have a paradigm mismatch!

Software Engineering / Fernando Brito e Abreu 6 7-Jun-05

Crisis? What Crisis?

$250 billion; 175,000 projects

31% of projects are cancelled = $81 billion 52.7% with 187% cost overrun = $59 billion 16 % on time in 1994 34 % on time in 2003, a big improvement!

Source: Standish Group International, 1994 and 2003 Surveys

4

Software Engineering / Fernando Brito e Abreu 7 7-Jun-05

Crisis? What Crisis?

Software bugs cost the U.S. economy an

estimated $59.5 billion annually, or about 0.6% of the gross domestic product (GDP)

Users shoulder more than half of the costs Developers and vendors bear the remainder

Source:

The Economic Impacts of Inadequate Infrastructure for Software Testing, Technical Report, National Institute of Standards and Technology, USA, May 2002 http://www.nist.gov/director/prog-ofc/report02-3.pdf

Software Engineering / Fernando Brito e Abreu 8 7-Jun-05

Crisis? What Crisis?

The user viewpoint …

47% 29% 19% 3% 2%

Delivered but never used with success (3200 KUSD) Paid but never delivered (1950 KUSD) Used but extensively modified (1300 KUSD) Used with some modifications (198 KUSD) Used without modifications (119 KUSD)

5

Software Engineering / Fernando Brito e Abreu 9 7-Jun-05

Failure Scenario

Ill-defined requirements Quickly evolving requirements No process defined Unrealistic planning Inappropriate tools Lack of user involvement Unable to detect problems in an initial phase Turnover in development teams Unqualified people Lack of quantitative based control mechanisms Reduced coverage of test battery

Software Engineering / Fernando Brito e Abreu 10 7-Jun-05

Success Scenario

Well defined responsibilities Correct estimation of schedule and costs More effective control of the development process Strong motivation of team members Strong involvement of users in req. specification Defined / repetitively adopted development process Less corrective and evolutive maintenance efforts Increased reliability of developed products Profit for all parties (win-win relationships): satisfied

users, clients and technical team members

6

Software Engineering / Fernando Brito e Abreu 11 7-Jun-05

Is Software Different?

Is software development so much

distinct from that of other products?

Does that prevent us from adopting

solutions from other more mature engineering fields?

Software Engineering / Fernando Brito e Abreu 12 7-Jun-05

Essential Differences in Software

According to Fred Brooks [Brooks87] :

• Complexity
• Alterability
• Invisibility

Source: Brooks, Frederick P. Jr. : ”No Silver Bullet: Essence and Accidents

• f Software Engineering", IEEE Computer, 20(4), April 1987.

7

Software Engineering / Fernando Brito e Abreu 13 7-Jun-05

Essential Differences in Software

Complexity

Lack of reuse Many pieces with fuzzy interfaces No laws of physics Human mind complexity

Software Engineering / Fernando Brito e Abreu 14 7-Jun-05

Essential Differences in Software

Alterability

“Curse” of flexibility User pressure on programmers Support for hardware evolution

Moore´s Law: semiconductor gate density will double every 18 months

(Gordon Moore, INTEL co-founder, 1965)

8

Software Engineering / Fernando Brito e Abreu 15 7-Jun-05

Essential Differences in Software

Invisibility

No single model with all

details

Multi-level graph structures

with fuzzy interconnection

Coupling produces

undesirable side-effects

Software Engineering / Fernando Brito e Abreu 16 7-Jun-05

Software Engineering !!!

9

Software Engineering / Fernando Brito e Abreu 17 7-Jun-05

Software Engineering is …

“The application of a systematic, disciplined, quantifiable approach to the development,

• peration, and maintenance of software; that

is, the application of engineering to software” Source:

IEEE Standard Glossary of Software Engineering Terminology,” IEEE, std 610.12-1990, 1990.

Software Engineering / Fernando Brito e Abreu 18 7-Jun-05

Some pre-historical roots

1958: John Tukey, the world-renowned statistician,

coined the term software

1968: The term software engineering was used in

the title of a NATO conference held in Germany

"Software Engineering: Report on a conference by the

NATO Science Committee," Peter Naur and Brian Randell (eds), January 1969

1972: The IEEE Computer Society first published

its Transactions on Software Engineering

10

Software Engineering / Fernando Brito e Abreu 19 7-Jun-05

Some pre-historical roots

1976: Creation of the IEEE committee for

developing software engineering standards

1979: Published the first software engineering

standard (IEEE Std 730 for software quality assurance plans). This standard was influential in many following standards:

configuration management software testing software requirements software design software verification and validation.

Software Engineering / Fernando Brito e Abreu 20 7-Jun-05

FAQs about Software Engineering (SE)

Is SE a branch of Computer Science? What is the ≠ between Science and Engineering? Which other disciplines is SE related to? If SE is Engineering, then it designates a

profession?

How can I recognize a profession when I see one?

11

Software Engineering / Fernando Brito e Abreu 21 7-Jun-05

Software Engineering is for Engineers!

Scientists extend our knowledge of the laws of

nature

Just as electrical engineering is based upon the science

• f Physics, software engineering should be based,

among others, upon Computer Science.

Engineers apply those laws of nature to build

useful artifacts, under a number of constraints

An engineer must be equipped with the essential

knowledge that supports the selection of the appropriate technology at the appropriate time in the appropriate circumstance

Software Engineering / Fernando Brito e Abreu 22 7-Jun-05

Other disciplines related to SE

Science disciplines

Computer science Mathematics Ergonomics Biology

Engineering and Management disciplines

Computer engineering Systems engineering Project management Quality management

12

Software Engineering / Fernando Brito e Abreu 23 7-Jun-05

Software Engineering

SE does not aim producing laws (it is not a science)

A Law is a theory or group of theories that has been

widely confirmed by intensive “in vivo” evidence (although being open to rebuttal)

However, several theories have been raised in SE

A theory is a conceptual framework that explains existing

facts or predicts new facts (by explaining cause-effect relationships in the product development life-cycle) Q1: Which theories have been raised in SE? Q2: Are there cause-effect relationships in the software development life-cycle?

Software Engineering / Fernando Brito e Abreu 24 7-Jun-05

Some Software Engineering “theories” …

Object-oriented systems are more extensible than

procedural systems

Software inspections are more efficient than testing Cohesion should be maximized and coupling should be

minimized in order to increment maintainability

Accurate effort estimates can be produced without a

detailed design (e.g. Function Points analysis)

The complexity of a software system increases non

linearly with its age (“Lehman’s “Law” of Sw Evolution)

Aspect-oriented languages improve modularity

13

Software Engineering / Fernando Brito e Abreu 25 7-Jun-05

Cause-effect relationships …

ACTIVITIES QUANTITATIVE EVALUATION PRODUCTS RESOURCES

Project planning and staffing Project management Requirements elicitation Designing Coding Configuration management Inspection Black-box testing Debugging Deployment User training Project plans Requirements specs Design models Source code Component libraries Estimation models Test batteries Executable code Installation manuals Process metrics Product metrics Improvement actions Improvement actions Project team members Users Methods Techniques Tools Operating System Hardware Physical Environment Schedule

Software Engineering / Fernando Brito e Abreu 26 7-Jun-05

Profession and Professionals

“The legitimization of professional authority involves three distinctive claims:

first, that the knowledge and competence of the

professional have been validated by a community of his

• r her peers;

second, that this consensually validated knowledge rests on

rational, scientific grounds;

and third, that the professional’s judgment and advice are

• riented toward a set of substantive values, such as health.

These aspects of legitimacy correspond to the kinds of attributes - collegial, cognitive, and moral - usually embodied in the term “profession.”

Source: P. Starr, The Social Transformation of American Medicine,

Basic Books, 1982, p. 15. (Pulitzer Prize-winning book)

14

Software Engineering / Fernando Brito e Abreu 27 7-Jun-05

Engineering Profession Components

An initial professional education in a curriculum validated by

society through accreditation

Registration of fitness to practice via voluntary certification

• r mandatory licensing

Specialized skill development and continuing professional

education

Communal support via a professional society A commitment to norms of conduct often prescribed in a

code of ethics

Source: G. Ford and N.E. Gibbs, A Mature Profession of Software

Engineering, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, Pa., tech. report CMU/SEI-96-TR-004, Jan. 1996.

Software Engineering / Fernando Brito e Abreu 28 7-Jun-05

SE maturity evidence: Courses

Several universities throughout the world

• ffer undergraduate degrees in software

engineering.

For example, such degrees are offered in:

University of New South Wales (Australia) McMaster University (Canada) Rochester Institute of Technology (US) University of Sheffield (UK) …

15

Software Engineering / Fernando Brito e Abreu 29 7-Jun-05

SE maturity evidence: Accreditation

There are bodies in charge of the

accreditation of undergraduate software engineering programs:

USA: Engineering Accreditation Commission of

the Accreditation Board for Engineering and Technology (ABET)

Canada: The Canadian Information Processing

Society has published criteria to accredit software engineering undergraduate programs

Software Engineering / Fernando Brito e Abreu 30 7-Jun-05

SE maturity evidence: Licensing

Examples of organizations licensing professional

software engineers

Texas Board of Professional Engineers Association of Professional Engineers and Geoscientists

• f British Columbia (APEGBC)

Professional Engineers of Ontario (PEO) IEEE CS offers the Certified Software Development

Professional certification for software engineering

Note: in Europe, in general, we are far behind

e.g. Portuguese Engineers Association (Ordem dos

Engenheiros) is still discussing basic principles

16

Software Engineering / Fernando Brito e Abreu 31 7-Jun-05

SE body of knowledge evidence

If there are:

accredited courses in SE certification or mandatory licensing schemes

in SE

professional societies for SE (e.g. IEEE

Computer Society) … then, a body of knowledge for SE must exist. Is it so?

Software Engineering / Fernando Brito e Abreu 32 7-Jun-05

A Profession’s Body of Knowledge

Every profession is based on a body of knowledge

(BOK) and recommended practices, although they are not always defined in a precise manner

When such formality does not exists, the body of

knowledge and recommended practices are “generally recognized” by practitioners

When formalized, usually a professional society or

related body maintains custody of it (e.g. PMI for project management knowledge)

17

Software Engineering / Fernando Brito e Abreu 33 7-Jun-05

Purposes for a Formal Body of Knowledge

accreditation of academic programs development of education and training

programs

certification of specialists, or professional

licensing

Q1: Is there a formal BOK for SE?

Software Engineering / Fernando Brito e Abreu 34 7-Jun-05

Summary

• Motivation

Motivation

• Course structure

Course structure

• Theory classes

Theory classes

• Lab classes

Lab classes Lab classes

• Evaluation

Evaluation Evaluation

• Bibliography

Bibliography Bibliography

18

Software Engineering / Fernando Brito e Abreu 35 7-Jun-05

Course structure Course structure -

• Theory classes

Theory classes

Follows the guide to the Software

Engineering Body of Knowledge (SWEBOK)

http://www.swebok.org

SWEBOK is a project of the IEEE Computer

Society Professional Practices Committee

http://computer.org

Software Engineering / Fernando Brito e Abreu 36 7-Jun-05

The Whole Picture

The SWEBOK is part of a more ambitious project, aimed at defining:

• 1. The required body of knowledge and recommended

practices (SWEBOK)

• 2. A code of ethics and professional practice for

software engineering

http://www.computer.org/certification/ethics.htm

Completed in 1998 and approved by both ACM and IEEE. It has

been adopted by numerous corporations and other organizations.

• 3. An educational curricula for undergraduate, graduate,

and continuing education

This is a joint effort IEEE CS / ACM, and was expected to be

completed in 2004.

19

Software Engineering / Fernando Brito e Abreu 37 7-Jun-05

SWEBOK Mission statement

“In this Guide, the IEEE Computer Society establishes for the first time a baseline for the body

• f knowledge for the field of software

engineering, and the work partially fulfills the Society’s responsibility to promote the advancement

• f both theory and practice in this field.”

The IEEE CS responsibility has historical roots …

Software Engineering / Fernando Brito e Abreu 38 7-Jun-05

SWEBOK Objectives

To promote a consistent view of SE worldwide To clarify the place - and set the boundary - of SE with

respect to other disciplines

computer science, project management, computer engineering,

mathematics, …

To characterize the contents of the SE discipline To provide a topical access to the SE Body of Knowledge To provide a foundation for curriculum development and for

individual certification and licensing material

20

Software Engineering / Fernando Brito e Abreu 39 7-Jun-05

SWEBOK: Which Knowledge?

Generally Accepted Knowledge (Yes)

Established practices recommended by many organizations Applies to most projects most of the time, and widespread

consensus validates its value and effectiveness

Specialized Knowledge (No)

Practices used only for certain types of software

Advanced and Research Knowledge (No)

Innovative practices tested and used only by some

• rganizations and concepts still being developed and

tested in research organizations

Software Engineering / Fernando Brito e Abreu 40 7-Jun-05

SWEBOK Participants

Steering Committee

Project Champion and Main Editors Associate Editors (one or more for each of the 10 KA’s)

Industrial Advisory Board Experts Panel (including R. Pressman and I. Sommerville) Reviewers (581 from 45 countries)

USA (310), Canada (73), Australia (25), UK (22), Spain (21),

Germany (12), Brazil (11), Italy (8), Netherlands (8), Japan (8), France (7), India (6), Israel (6), … Portugal (2)!

21

Software Engineering / Fernando Brito e Abreu 41 7-Jun-05

SWEBOK: the 10 Knowledge Areas

Software Requirements Software Design Software Construction Software Testing Software Maintenance Software Configuration Management Software Engineering Management Software Engineering Process Software Engineering Tools and Methods Software Quality

Software Engineering / Fernando Brito e Abreu 42 7-Jun-05

KA1: Software Requirements

A requirement is a property that must be exhibited in order to solve some real-world problem

Sub-areas:

Software Requirements Fundamentals Requirements Process Requirements Elicitation Requirements Analysis Requirements Specification Requirements Validation Practical Considerations

22

Software Engineering / Fernando Brito e Abreu 43 7-Jun-05

KA2: Software Design

Design is both “the process of defining the architecture, components, interfaces, and other characteristics of a system or component” and “the result of that process.” Source: [IEEE610.12-90]

Sub-areas:

Software Design Fundamentals Key Issues in Software Design Software Structure and Architecture, Design Quality Analysis and Evaluation Software Design Notations Software Design Strategies and Methods

Software Engineering / Fernando Brito e Abreu 44 7-Jun-05

KA3: Software Construction

Construction refers to the detailed creation of working, meaningful software through a combination of coding, verification, unit testing, integration testing, and debugging.

Sub-areas:

Software Construction Fundamentals Managing Construction Practical Considerations

23

Software Engineering / Fernando Brito e Abreu 45 7-Jun-05

KA4: Software Testing

Testing consists of the dynamic verification of the behavior of a program on a finite set of test cases, suitably selected from the usually infinite executions domain, against the expected behavior.

Sub-areas:

Software Testing Fundamentals Test Levels Test Techniques Test-Related Measures Test Process

Software Engineering / Fernando Brito e Abreu 46 7-Jun-05

KA5: Software Maintenance

Once in operation, anomalies are uncovered, operating environments change, and new user requirements surface. The maintenance phase of the life cycle commences upon delivery, but maintenance activities occur much earlier.

Sub-areas:

Software Maintenance Fundamentals Key Issues in Software Maintenance Maintenance Process Techniques for Maintenance

24

Software Engineering / Fernando Brito e Abreu 47 7-Jun-05

KA6: Sw Configuration Management

Software Configuration Management (SCM) is the discipline of identifying the configuration of software at distinct points in time for the purpose of systematically controlling changes to the configuration and of maintaining the integrity and traceability of the configuration throughout the system life cycle.

Sub-areas:

Management of the SCM Process Software Configuration Identification Software Configuration Control Software Configuration Status Accounting Software Configuration Auditing Software Release Management and Delivery

Software Engineering / Fernando Brito e Abreu 48 7-Jun-05

KA7: Sw Engineering Management

This KA addresses the management and measurement of software engineering. While measurement is an important aspect of all KAs, it is here that the topic of measurement programs is presented.

Sub-areas:

Initiation and Scope Definition Software Project Planning Software Project Enactment Review and Evaluation Closure Software Engineering Measurement

25

Software Engineering / Fernando Brito e Abreu 49 7-Jun-05

KA8: Software Engineering Process

The Software Engineering Process KA is concerned with the definition, implementation, assessment, measurement, management, change, and improvement of the software engineering process itself.

Sub-areas:

Process Implementation and Change Process Definition Process Assessment. Process and Product Measurements

Software Engineering / Fernando Brito e Abreu 50 7-Jun-05

KA9: Sw Engineering Tools and Methods

The Software Engineering Tools and Methods KA includes both software engineering tools and software engineering methods.

Sub-areas:

Software Engineering Tools Software Engineering Methods

26

Software Engineering / Fernando Brito e Abreu 51 7-Jun-05

KA10: Software Quality

This KA deals with software quality considerations which transcend the software life cycle processes. Since software quality is a ubiquitous concern in software engineering, it is also considered in many of the other KAs.

Sub-areas:

Software Quality Fundamentals Software Quality Management Practical Considerations

Software Engineering / Fernando Brito e Abreu 52 7-Jun-05

27

Software Engineering / Fernando Brito e Abreu 53 7-Jun-05 Software Engineering / Fernando Brito e Abreu 54 7-Jun-05

The World Out There …

A Software House

PT-SI, Tagus Park

A Tool / Knowledge Vendor

SINFIC, FCT or IBM premises

A Large User

(?)

28

Software Engineering / Fernando Brito e Abreu 55 7-Jun-05

Summary

• Motivation

Motivation

• Course structure

Course structure

• Theory classes

Theory classes

• Lab classes

Lab classes

• Evaluation

Evaluation Evaluation

• Bibliography

Bibliography Bibliography

Software Engineering / Fernando Brito e Abreu 56 7-Jun-05

Lab Classes

Component based development Market simulation (competition) Standardization simulation Large teams

29

Software Engineering / Fernando Brito e Abreu 57 7-Jun-05

Summary

• Motivation

Motivation

• Course structure

Course structure

• Theory classes

Theory classes

• Lab classes

Lab classes

• Evaluation

Evaluation

• Bibliography

Bibliography Bibliography

Software Engineering / Fernando Brito e Abreu 58 7-Jun-05

Evaluation

The formula!

65% Exam + 35% Lab Assignment

(with 5% correction depending on Labs outcome)

30

Software Engineering / Fernando Brito e Abreu 59 7-Jun-05

Summary

• Motivation

Motivation

• Course structure

Course structure

• Theory classes

Theory classes

• Lab classes

Lab classes

• Evaluation

Evaluation

• Bibliography

Bibliography

Software Engineering / Fernando Brito e Abreu 60 7-Jun-05

Bibliography (main)

IEEE Computer Society, Guide to the Software

Engineering Body of Knowledge (SWEBOK), 2004.

http://www.swebok.org

Roger Pressman, Software Engineering: a

Practitioner's Approach, 6th edition, McGraw-Hill, 2005.

Software Engineering Resources (http://www.rspa.com/)

Ian Sommerville, Software Engineering, 7th Edition,

Addison-Wesley, 2004.

http://www.comp.lancs.ac.uk/computing/resources/IanS/

31

Software Engineering / Fernando Brito e Abreu 61 7-Jun-05

Bibliography (complementary)

Stephen Schach, Object-Oriented and Classical

Software Engineering, 5th Edition, 2001.

http://www.mhhe.com/engcs/compsci/schach5/

Software Engineering / Fernando Brito e Abreu 62 7-Jun-05

Chapters cross-reference

spread spread spread

• Sw. Eng. Tools

KA9 1, 3 1 1 Introduction Motivation 24 3, 25 4, 22, 23 29 26, 27, 28 19,20 8 10, 14 5, 6 Sommerville 4, 8, 15, 22, 26 2, 3, 4, 21 3,5,6,7,23,24,25 27 31 13, 14

• 9, 10, 11

7, 8 Pressman 8 Software Quality KA10 2

• Sw. Eng. Process

KA8 4, 9

• Sw. Eng. Manag.

KA7 5

• Config. Managem.

KA6 16

• Sw. Maintenance

KA5 6

• Sw. Testing

KA4 14, 15

• Sw. Construction

KA3 7, 13

• Sw. Design

KA2 10, 11,12

• Sw. Requirements

KA1 Schach Description SWEBOK