4. 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
20-Sep-11 Software Engineering / Fernando Brito e Abreu 4
5. Are Professors to Blame?
“Real world” - Programming in the large
largeteams, large overheads, deliverables often late, over
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!
20-Sep-11 Software Engineering / Fernando Brito e Abreu 5
6. 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
20-Sep-11 Software Engineering / Fernando Brito e Abreu 6
7. 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
20-Sep-11 Software Engineering / Fernando Brito e Abreu 7
8. Crisis? What Crisis?
The user viewpoint …
Delivered but never used with success (3200 KUSD)
Paid but never delivered (1950 KUSD)
2% Used but extensively modified (1300 KUSD)
Used with some modifications (198 KUSD)
3% Used without modifications (119 KUSD)
19%
47%
29%
20-Sep-11 Software Engineering / Fernando Brito e Abreu 8
9. 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
20-Sep-11 Software Engineering / Fernando Brito e Abreu 9
10. 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
20-Sep-11 Software Engineering / Fernando Brito e Abreu 10
11. 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?
20-Sep-11 Software Engineering / Fernando Brito e Abreu 11
12. Essential Differences in Software
According to Fred Brooks:
Complexity
Alterability
Invisibility
Source:
[Brooks87] Brooks, Frederick P. Jr. : ”No Silver Bullet: Essence and
Accidents of Software Engineering", IEEE Computer, 20(4), April 1987.
20-Sep-11 Software Engineering / Fernando Brito e Abreu 12
13. Essential Differences in Software
Complexity
Lack of reuse
Many pieces with fuzzy interfaces
No laws of physics
Human mind complexity
20-Sep-11 Software Engineering / Fernando Brito e Abreu 13
14. 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)
20-Sep-11 Software Engineering / Fernando Brito e Abreu 14
15. Essential Differences in Software
Invisibility
No single model with all details
Multi-level graph structures
with fuzzy interconnection
Coupling produces undesirable
side-effects
20-Sep-11 Software Engineering / Fernando Brito e Abreu 15
17. 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”
Source:
IEEE Standard Glossary of Software Engineering
Terminology,” IEEE, std 610.12-1990, 1990.
20-Sep-11 Software Engineering / Fernando Brito e Abreu 17
18. 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
20-Sep-11 Software Engineering / Fernando Brito e Abreu 18
19. 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
20-Sep-11 Software Engineering / Fernando Brito e Abreu 19
20. 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?
20-Sep-11 Software Engineering / Fernando Brito e Abreu 20
21. Software Engineering is for Engineers!
Scientists extend our knowledge of the laws of nature
Just as electrical engineering is based upon the science of
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
20-Sep-11 Software Engineering / Fernando Brito e Abreu 21
22. Other disciplines related to SE
Engineering and
Science disciplines Management disciplines
Computer science Computer engineering
Mathematics Systems engineering
Ergonomics Project management
Biology Quality management
20-Sep-11 Software Engineering / Fernando Brito e Abreu 22
23. Software Engineering
SE does not aim to produce laws (like Sciences do)
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? Engineering / Fernando Brito e Abreu 23
20-Sep-11 Software
24. 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 over object-
oriented systems
20-Sep-11 Software Engineering / Fernando Brito e Abreu 24
25. Cause-effect relationships …
Project planning and staffing Project plans
Project management Requirements specs
Project team members
Requirements elicitation Design models
Users
Designing Source code
Methods
Coding Component libraries
Techniques
Configuration management Estimation models
Tools
Inspection Test batteries
Operating System
Black-box testing Executable code
Hardware
Debugging Installation manuals
Physical Environment
Deployment
Schedule
User training
PRODUCTS
RESOURCES ACTIVITIES
Process metrics Improvement actions
Improvement actions
QUANTITATIVE
EVALUATION
Product metrics
20-Sep-11 Software Engineering / Fernando Brito e Abreu 25
26. Profession and Professionals
Claims for legitimization of a professional authority:
1. Collegial claim: the knowledge and competence of the
professional have been validated by a community (peers)
2. Cognitive claim: this consensually validated knowledge rests on
rational, scientific grounds
3. Moral claim: the professional’s judgment and advice are oriented
toward a set of substantive values (e.g. health)
Source: P. Starr, The Social Transformation of American Medicine, Basic Books,
1982, p. 15. (Pulitzer Prize-winning book)
20-Sep-11 Software Engineering / Fernando Brito e Abreu 26
27. Engineering Profession Components
An initial professional education in a curriculum validated by
society through accreditation
Registration of fitness to practice via voluntary certification or
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.
20-Sep-11 Software Engineering / Fernando Brito e Abreu 27
28. SE maturity evidence: Courses
Several universities throughout the world offer
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)
…
20-Sep-11 Software Engineering / Fernando Brito e Abreu 28
29. 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
Europe: ENQA (European Association for Quality Assurance
in Higher Education)
Portugal:
Before: Ordem dos Engenheiros
From now on: Agência de Avaliação e Acreditação do Ensino Superior
(Decreto Lei n.º 38/2007, de 16 de Agosto)
20-Sep-11 Software Engineering / Fernando Brito e Abreu 29
30. SE maturity evidence: Licensing
Examples of organizations licensing professional
software engineers
Texas Board of Professional Engineers
Association of Professional Engineers and Geoscientists of
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
20-Sep-11 Software Engineering / Fernando Brito e Abreu 30
31. 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?
20-Sep-11 Software Engineering / Fernando Brito e Abreu 31
32. 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
PMI for Project Management knowledge (PMBoK)
IEEE for Software Engineering knowledge
20-Sep-11 Software Engineering / Fernando Brito e Abreu 32
33. 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?
20-Sep-11 Software Engineering / Fernando Brito e Abreu 33
35. Course structure - Theory classes
Tries to cover as much as possible the topics
defined in the guide to the Software Engineering
Body of Knowledge (SWEBOK)
SWEBOK is a project of the IEEE Computer
Society Professional Practices Committee
20-Sep-11 Software Engineering / Fernando Brito e Abreu 35
36. 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
Produced by the ACM/IEEE-CS Joint Task Force on Software Engineering
Ethics and Professional Practices and jointly approved by the ACM and the
IEEE-CS as the standard for teaching and practicing software engineering
3. An educational curricula for undergraduate, graduate, and
continuing education
This is a joint effort IEEE CS / ACM
Last edition is the CS2008
20-Sep-11 Software Engineering / Fernando Brito e Abreu 36
37. SWEBOK Mission statement
“In this Guide, the IEEE Computer Society establishes for
the first time a baseline for the body of knowledge for
the field of software engineering, and the work partially
fulfills the Society’s responsibility to promote the
advancement of both theory and practice in this field.”
The IEEE CS responsibility has historical roots …
20-Sep-11 Software Engineering / Fernando Brito e Abreu 37
38. 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-Sep-11 Software Engineering / Fernando Brito e Abreu 38
39. 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 organizations
and concepts still being developed and tested in research
organizations
20-Sep-11 Software Engineering / Fernando Brito e Abreu 39
40. 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)!
20-Sep-11 Software Engineering / Fernando Brito e Abreu 40
41. 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
20-Sep-11 Software Engineering / Fernando Brito e Abreu 41
42. 20-Sep-11 Software Engineering / Fernando Brito e Abreu 42
43. 20-Sep-11 Software Engineering / Fernando Brito e Abreu 43
44. 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
20-Sep-11 Software Engineering / Fernando Brito e Abreu 44
45. 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: IEEE Std 610.12 - Standard Glossary of Software Engineering
Terminology, IEEE Standards Association, 1990
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
20-Sep-11 Software Engineering / Fernando Brito e Abreu 45
46. 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
20-Sep-11 Software Engineering / Fernando Brito e Abreu 46
47. 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
20-Sep-11 Software Engineering / Fernando Brito e Abreu 47
48. 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
20-Sep-11 Software Engineering / Fernando Brito e Abreu 48
49. 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
20-Sep-11 Software Engineering / Fernando Brito e Abreu 49
50. 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
20-Sep-11 Software Engineering / Fernando Brito e Abreu 50
51. 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
20-Sep-11 Software Engineering / Fernando Brito e Abreu 51
52. 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
20-Sep-11 Software Engineering / Fernando Brito e Abreu 52
53. 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
20-Sep-11 Software Engineering / Fernando Brito e Abreu 53
55. Lab Classes
Organization
Labs will be organized around a set of
assignments
Instructions regarding each assignment will be
given in the theoretical classes
Each assignment can have a different duration
(e.g. from 1 week to a full month)
20-Sep-11 Software Engineering / Fernando Brito e Abreu 55
58. Evaluation
The formula!
40% Lab Assignments
20% Microtests
40% Exam
Allcomponents will be graded with one decimal
You will get access to the exam only if you were
successful in the labs and microtests (grade >= 8/20)
The exam also has a minimum grade of 8/20
20-Sep-11 Software Engineering / Fernando Brito e Abreu 58
59. Lab Assignments
Each assignment will have a maximum number
of grading points
Labs final grade will be 20 * the achieved
percentage of the maximum achievable points
(sum of points for each assignment)
20-Sep-11 Software Engineering / Fernando Brito e Abreu 59