2011/09/13 - introduction

Software Engineering I - Introduction -

Fernando Brito e Abreu

DCTI / ISCTE-IUL QUASAR Research Group

mailto:[email protected]

http://www.dcti.iscte.pt/






http://ctp.di.fct.unl.pt/QUASAR

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

Summary

Motivation

Course structure

Theory classes

Lab classes

Evaluation

Bibliography


Summary

Motivation

Course structure

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

large teams, 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

http://www.nist.gov/director/planning/upload/report02-3.pdf

http://www.nist.gov/director/planning/upload/report02-3.pdf



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)


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.

http://en.wikipedia.org/wiki/No_Silver_Bullet

http://en.wikipedia.org/wiki/No_Silver_Bullet



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

Science disciplines

Computer science

Mathematics

Ergonomics

Biology

Engineering and

Management disciplines

Computer engineering

Systems engineering

Project management

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?


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 …

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


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)

http://www.a3es.pt/


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

Course structure

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

http://www.swebok.org/

http://www.swebok.org/

http://computer.org/

http://computer.org/


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

http://www.acm.org/about/se-code

http://www.acm.org/about/se-code

http://www.acm.org/education/curricula-recommendations

http://www.acm.org/education/curricula-recommendations

http://www.acm.org/education/curricula/ComputerScience2008.pdf


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

http://standards.ieee.org/reading/ieee/std_public/description/se/610.12-1990_desc.html






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

Course structure

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

Course structure

Theory classes

Lab classes

Evaluation

Bibliography


Evaluation

The formula!

40% Lab Assignments

20% Microtests

40% Exam

All components 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

Course structure

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

http://www.rspa.com/sepa7e.html


http://highered.mcgraw-hill.com/sites/0073375977/information_center_view0/



http://www.cs.st-andrews.ac.uk/~ifs/Books/SE9/

http://www.pearsonhighered.com/educator/product/Software-Engineering/9780137035151.page



http://www.vuse.vanderbilt.edu/~srs/








Main:

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








Main:

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


http://www.cs.st-andrews.ac.uk/~ifs/Books/SE9/





Complementary:

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









ID1 (2011/2012)


EIC1 (2011/2012)
