2011/09/13 - Introduction

Software Engineering I
- Introduction -

Fernando Brito e Abreu
DCTI / ISCTE-IUL
QUASAR Research Group

Summary
 Motivation
 Course structure
 Theory classes
 Lab classes

 Evaluation
 Bibliography

20-Sep-11 Software Engineering / Fernando Brito e Abreu 2

Summary
 Motivation
Theory classes
Lab classes
 Evaluation
 Bibliography


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

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!


 $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


 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


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%


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

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

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?


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.


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


 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)

 Invisibility
 No single model with all details
 Multi-level graph structures
with fuzzy interconnection
 Coupling produces undesirable
side-effects


Software Engineering !!!


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.


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

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

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?


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


Other disciplines related to SE
Engineering and
Science disciplines Management disciplines

 Computer science  Computer engineering
 Mathematics  Systems engineering
 Ergonomics  Project management
 Biology  Quality management


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

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


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

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)


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.


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)
…


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)


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


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?


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


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?

Summary
 Motivation
Theory classes
Lab classes
 Evaluation
 Bibliography


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


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

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 …


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


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

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)!


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

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


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

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


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


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


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


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


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


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


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


Summary
 Motivation
Theory classes
Lab classes
 Evaluation
 Bibliography


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)


Lab Classes
Topics (examples)
 White-box testing and defect tracking
 Technology assessment
 Requirements specification and black-box testing
 Software inspections (formal V&V technique)
 Configuration management
 Issue tracking
 Software maintenance experience


Summary
 Motivation
Theory classes
Lab classes
 Evaluation
 Bibliography


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

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)


Summary
 Motivation
Theory classes
Lab classes
 Evaluation
 Bibliography


Bibliography (books)
Main:
 Roger Pressman, Software Engineering: a Practitioner's
Approach, 7th edition, McGraw-Hill, 2009
 Ian Sommerville, Software Engineering, 9th Edition,
Addison-Wesley, 2010

Complementary:
 Stephen Schach, Object-Oriented and Classical
Software Engineering, 8th Edition, McGraw-Hill, 2011


Main:
 Roger Pressman,
Software Engineering: a
Practitioner's Approach,
7th edition, McGraw-Hill,
2009


Main:
 Ian Sommerville,
Software Engineering,
9th Edition, Addison-
Wesley, 2010


Complementary:
 Stephen Schach, Object-
Oriented and Classical
Software Engineering, 8th
Edition, McGraw-Hill,
2011


ID1 (2011/2012)


EIC1 (2011/2012)


2011/09/13 - Introduction

Recomendados

Recomendados

Más contenido relacionado

Similar a 2011/09/13 - Introduction

Similar a 2011/09/13 - Introduction (20)

Último

Último (20)

2011/09/13 - Introduction