Transcript Project management

Ingeniería de Software

Diseño, construcción y mantenimiento de
sistemas de software grandes.
Dr. Pedro Mejía Alvarez.
CINVESTAV-IPN, México
©Sommerville 2000, Medvidovic 2006, Mejia 2009,
Introduction to Software Engineering
Slide 1
Introduction


Getting started with software
engineering
Objectives
•
•
To introduce software engineering and to explain its
importance
To set out the answers to key questions about
software engineering
©Sommerville 2000, Medvidovic 2006, Mejia 2009,
Introduction to Software Engineering
Slide 2
Introduction
why is software so hard?
and what can we do about it?
©Sommerville 2000, Medvidovic 2006, Mejia 2009,
Introduction to Software Engineering
Slide 3
How’s our personal software?
Software warranties, 2007
Apple
“Except for the limited warranty on media ... software is
provided “as is”, with all faults and without warranty of
any kind...”
Google
“as is, with no warranties whatsoever”
Microsoft
“substantially in accordance with the accompanying
materials, for a period of 90 days...”
©Sommerville 2000, Medvidovic 2006, Mejia 2009,
Introduction to Software Engineering
Slide 4
Is your PC secure?
typical patch size
‣ 100MB
typical time to download
‣ 10 minutes
average time to infection*
‣ 4 minutes
[Windows XP, default firewall settings] Unprotected PCs Fall To Hacker Bots In
Just Four Minutes
Gregg Keizer; Nov 30, 2004; http://www.techweb.com/wire/security/54201306
From: Security Absurdity: The Complete, Unquestionable, And Total Failure of
Information Security, Noam Eppel; http://securityabsurdity.com
©Sommerville 2000, Medvidovic 2006, Mejia 2009,
Introduction to Software Engineering
Slide 5
What about our operating systems ?
©Sommerville 2000, Medvidovic 2006, Mejia 2009,
Introduction to Software Engineering
Slide 6
What about our web browsers ?
dependences between DLLs
‣ disciplined layering
why IE killed Netscape?
‣ spaghetti code in both
‣ but IE3 rebuilt from scratch
dependences in internet explorer
graph from http://www.spinellis.gr/blog/20031003
for Netscape story see:
Competing on Internet Time: Lessons From Netscape & Its
Battle with Microsoft
by Michael A. Cusumano and David B. Yoffie
©Sommerville 2000, Medvidovic 2006, Mejia 2009,
Introduction to Software Engineering
Slide 7
Sample failures in Systems build for the
government?
Navy enterprise resource planning
‣ $1B wasted on systems that don’t interoperate
NASA financial systems
‣ after 12 years and $120M spent, on third attempt
expected to cost $1B
‣ still cannot produce auditable financial statements
Department of Veterans’ Affairs
‣ supplies not available for patients due to bad
inventory control
‣ implementation halted after spending $250M
©Sommerville 2000, Medvidovic 2006, Mejia 2009,
Introduction to Software Engineering
Slide 8
Sample failures in Systems build for the
government (FBI)?
reacting to 9/11
‣ had to send photos of suspected hijackers by fax
‣ no PCs for most employees, no secure email for images
Trilogy
‣ new network, thousands of PCs, software system (“VCF”)
‣ contract awarded to SAIC
National Research Council report, 2004
‣ agents can’t take copies of cases into the field
‣ no bookmarking or history to help navigation, no sorting
outcome
‣ $600M later, no system; Sentinel ($425M) planned for 2009
©Sommerville 2000, Medvidovic 2006, Mejia 2009,
Introduction to Software Engineering
Slide 9
Critical systems (why they fail ?)
South Africa, October 2007
‣ antiaircraft cannon kills 9 soldiers and injures 14 others
‣ cause not known, but software suspected
http://blog.wired.com/defense/2007/10/robot-cannon-ki.html
©Sommerville 2000, Medvidovic 2006, Mejia 2009,
Introduction to Software Engineering
Slide 10
Critical systems (why they fail ?)
A radar system that was supposed to warn low-flying planes of nearby obstacles was plagued with problems
and fixed nationwide only after a 1997 fatal airplane crash on Guam, according to a published report. In
some cases, programming errors caused the Minimum Safe-Altitude Warning system not to operate over
wide areas, including near busy airports such as those in Chicago and Dallas-Ft. Worth. In other cases,
false alarms were so numerous that air traffic controllers placed cardboard over warning speakers to
silence the noise. The Federal Aviation Administration was warned about the trouble after a business jet
Crashed outside Washington in 1994, but it did not take decisive action to resolve it until after a Korean Air
jumbo jet slammed into a hill on approach to Guam in August 1997, killing 228. AP, Oct 1999;
http://ns.gov.gu/guam/indexmain.html
most aviation deaths from
“controlled flight into
terrain”
©Sommerville 2000, Medvidovic 2006, Mejia 2009,
Introduction to Software Engineering
Slide 11
Critical systems (why they fail ?)
ARIANE Flight 501




Disintegration after 39 sec
Caused by large correction for attitude
deviation
Caused by wrong data being sent to On
Board Computer
Caused by software exception in Inertial
Reference System after 36 sec.
IEEE Computer, jan. 1997, p. 129-130
http://www.cs.vu.nl/~hans/ariane5report.html
©Sommerville 2000, Medvidovic 2006, Mejia 2009,
Introduction to Software Engineering
Slide 12
How do we get here ?
Magnetic disks, US$/gigabyte
From Frans Kaashoek and Jerome Saltzer, Topics in the Engineering of
Computer Systems, to appear.
©Sommerville 2000, Medvidovic 2006, Mejia 2009,
Introduction to Software Engineering
Slide 13
How do we get here ?
operating system growth size in millions of lines of code
From Frans Kaashoek and Jerome Saltzer, Topics in the Engineering of Computer Systems.
©Sommerville 2000, Medvidovic 2006, Mejia 2009,
Introduction to Software Engineering
Slide 14
Fundamental challenges:
context, state space, coupling
a software system is a component
‣ interacts with physical environment
‣ and organizational context of operators & users
sources of defects
‣ < 3% of software failures due to bugs in code
‣ >90% from poor understanding of requirements
consequences
‣ requirements analysis is critical
‣ not just function, also assumptions
©Sommerville 2000, Medvidovic 2006, Mejia 2009,
Introduction to Software Engineering
Slide 15
Fundamental challenges:
context, state space, coupling
state space complexity
software systems have huge state space
‣ in lifetime, small proportion covered
‣ in testing, hardly any covered
implications
‣ “Program testing can be used to show the
presence of bugs, but never to show their absence!”
‣ often running in uncharted territory
*E.W. Dijkstra, Structured programming (EWD268)
http://www.cs.utexas.edu/users/EWD/
©Sommerville 2000, Medvidovic 2006, Mejia 2009,
Introduction to Software Engineering
Slide 16
Central themes




SE is concerned with
BIG programs
complexity is an issue
software evolves
development must be
efficient
©Sommerville 2000, Medvidovic 2006, Mejia 2009,




you’re doing it together
software must
effectively support users
involves different
disciplines
SE is a balancing act
Introduction to Software Engineering
Slide 17
Relative distribution of
software/hardware costs
100
Percent of total cost
Hardware
Development
60
Software
20
1955
Maintenance
1970
Year
1985
Why does software maintenance cost so much?
©Sommerville 2000, Medvidovic 2006, Mejia 2009,
Introduction to Software Engineering
Slide 18
Global distribution of effort
design 15%
coding 20%
requirements
engineering 10%
specification 10%
testing 45%
©Sommerville 2000, Medvidovic 2006, Mejia 2009,
Introduction to Software Engineering
Slide 19
Engineering



Engineering is …
•
The application of scientific principles and methods
•
To the construction of useful structures & machines
Examples
•
Mechanical engineering
•
Civil engineering
•
Chemical engineering
•
Electrical engineering
•
Nuclear engineering
•
Aeronautical engineering
Why other areas of science and engineering are doing things better than
Software Engineering ?
©Sommerville 2000, Medvidovic 2006, Mejia 2009,
Introduction to Software Engineering
Slide 20
Electrical Engineering
©Sommerville 2000, Medvidovic 2006, Mejia 2009,
Introduction to Software Engineering
Slide 21
Architecture & Civil Engineering
©Sommerville 2000, Medvidovic 2006, Mejia 2009,
Introduction to Software Engineering
Slide 22
Control Systems
©Sommerville 2000, Medvidovic 2006, Mejia 2009,
Introduction to Software Engineering
Slide 23
Process & Chemical Engineering
©Sommerville 2000, Medvidovic 2006, Mejia 2009,
Introduction to Software Engineering
Slide 24
Software Engineering

The term is 40 years old: NATO
Conferences
•
•

Garmisch, Germany, October 7-11, 1968
Rome, Italy, October 27-31, 1969
The reality is finally beginning to arrive
•
Computer science as the scientific basis
• Other scientific bases?
©Sommerville 2000, Medvidovic 2006, Mejia 2009,
Introduction to Software Engineering
Slide 25
Software Engineering in a Nutshell

Development of software systems whose
size/complexity warrants team(s) of engineers
•

Scope
•

multi-person construction of multi-version software
[Parnas 1987]
study of software process, development principles, techniques,
and notations
Goal
•
production of quality software, delivered on time, within budget,
satisfying customers’ requirements and users’ needs
©Sommerville 2000, Medvidovic 2006, Mejia 2009,
Introduction to Software Engineering
Slide 26
Why software engineering





The economies of ALL developed nations are
dependent on software
More and more systems are software controlled
Software engineering is concerned with theories,
methods and tools for professional software
development
Software engineering expenditure represents a
significant fraction of GNP in all developed countries
Software failures are ever more visible and costly
©Sommerville 2000, Medvidovic 2006, Mejia 2009,
Introduction to Software Engineering
Slide 27
Ever-Present Difficulties



Few guiding scientific principles
Few universally applicable methods
As much
managerial / psychological / sociological
as technological
©Sommerville 2000, Medvidovic 2006, Mejia 2009,
Introduction to Software Engineering
Slide 28
Why These Difficulties?

SE is a unique brand of engineering
•
•
•
•
•
Software is malleable
Software construction is human-intensive
Software is intangible
Software problems are unprecedentedly complex
Software directly depends upon the hardware
• It is at the top of the system engineering “food chain”
•
•
Software solutions require unusual rigor
Software has discontinuous operational nature
©Sommerville 2000, Medvidovic 2006, Mejia 2009,
Introduction to Software Engineering
Slide 29
Software Engineering ≠ Software
Programming

Software programming
•
•
•
•
Single developer
“Toy” applications
Short lifespan
Single or few stakeholders
• Architect = Developer = Manager = Tester = Customer = User
•
•
•
One-of-a-kind systems
Built from scratch
Minimal maintenance
©Sommerville 2000, Medvidovic 2006, Mejia 2009,
Introduction to Software Engineering
Slide 30
Software Engineering ≠ Software
Programming

Software engineering
•
•
•
•
Teams of developers with multiple roles
Complex systems
Indefinite lifespan
Numerous stakeholders
• Architect ≠ Developer ≠ Manager ≠ Tester ≠ Customer ≠ User
•
•
•
System families
Reuse to amortize costs
Maintenance accounts for over 60% of overall
development costs
©Sommerville 2000, Medvidovic 2006, Mejia 2009,
Introduction to Software Engineering
Slide 31
Software costs



Software costs often dominate system costs. The
costs of software on a PC are often greater than
the hardware 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 costeffective software development
©Sommerville 2000, Medvidovic 2006, Mejia 2009,
Introduction to Software Engineering
Slide 32
Economic and Management
Aspects of SE


Software production =
development + maintenance (evolution)
Maintenance costs > 60% of all development
costs
•
•
•

20% corrective
30% adaptive
50% perfective
Quicker development is not always preferable
•
•
higher up-front costs may defray downstream costs
poorly designed/implemented software is a critical cost factor
©Sommerville 2000, Medvidovic 2006, Mejia 2009,
Introduction to Software Engineering
Slide 33
Relative Costs of Fixing
Software Faults
200
30
10
1
Requirements
2
Specification
3
Planning
©Sommerville 2000, Medvidovic 2006, Mejia 2009,
4
Design
Implementation
Integration
Introduction to Software Engineering
Maintenance
Slide 34
Mythical Man-Month
by Fred Brooks

Published in 1975, republished in 1995
•

Central argument
•
•

Large projects suffer management problems different in kind than small
ones, due to division in labor
Critical need is the preservation of the conceptual integrity of the
product itself
Central conclusions
•
•

Experience managing development of OS/360 in 1964-65
Conceptual integrity achieved through chief architect
Implementation achieved through well-managed effort
Brooks’s Law
•
Adding personnel to a late project makes it later
©Sommerville 2000, Medvidovic 2006, Mejia 2009,
Introduction to Software Engineering
Slide 35
FAQs about software engineering
1.
2.
3.
What is software?
What is software engineering?
What is the difference between software engineering and
computer science?
4. What is the difference between software engineering and
system engineering?
5. What is a software process?
6. What are the costs of software engineering?
7. What are software engineering methods?
8. What are the attributes of good software?
9. What are the key challenges facing software engineering?
©Sommerville 2000, Medvidovic 2006, Mejia 2009,
Introduction to Software Engineering
Slide 36
What is software?

Computer programs and associated
documentation
•


Often referred to as “artifacts”
Software products may be developed for a
particular customer or may be developed for a
general market
Software products may be
•
•
Generic - developed to be sold to a range of different customers
Custom - developed for a single customer according to the
customer’s specification
©Sommerville 2000, Medvidovic 2006, Mejia 2009,
Introduction to Software Engineering
Slide 37
What is software engineering?


Software engineering is an engineering discipline which
is concerned with all aspects of software production
Software engineers should adopt a systematic and
organised approach to their work and use appropriate
tools and techniques depending on
•
•
•

the problem to be solved,
the development constraints, and
the resources available
A key software engineering “axiom”
•
•
•
Better
Cheaper
Faster
pick any two
©Sommerville 2000, Medvidovic 2006, Mejia 2009,
Introduction to Software Engineering
Slide 38
What is the difference between software
engineering and 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 currently
insufficient to act as a complete underpinning for
software engineering
©Sommerville 2000, Medvidovic 2006, Mejia 2009,
Introduction to Software Engineering
Slide 39
What is the difference between software
engineering and system engineering?

System engineering is concerned with all aspects
of computer-based systems development
including hardware, software and process
engineering.
•

Software engineering is a “component” in this process
System engineers are involved in overall system
specification, architectural design, integration and
deployment
©Sommerville 2000, Medvidovic 2006, Mejia 2009,
Introduction to Software Engineering
Slide 40
What is a software process?


A set of activities whose goal is the development
or evolution of software
Generic activities in all software processes are:
•
•
•
•
Specification - what the system should do and its development
constraints
Development - production of the software system
Validation - checking that the software is what the customer
wants
Evolution - changing the software in response to changing
demands
©Sommerville 2000, Medvidovic 2006, Mejia 2009,
Introduction to Software Engineering
Slide 41
What are the costs of software engineering?



Roughly 60% of costs are development costs, 40% are
testing costs
Evolution costs often far exceed development costs
Costs vary depending on
•
The type of system being developed
• E.g., custom built vs. mass market software
•
•

The requirements of system attributes such as performance and system
reliability
The experience of the development team(s)
Distribution of costs depends on the development model
that is used
©Sommerville 2000, Medvidovic 2006, Mejia 2009,
Introduction to Software Engineering
Slide 42
What are software engineering methods?

Structured approaches to software development
which include system
•
Models
• Why are models needed?
•
Notations
• Such as?
•
•
•

Rules - Constraints applied to system models
Design advice - recommendations on good design practice
Process guidance - what activities to follow
What are some example methods?
©Sommerville 2000, Medvidovic 2006, Mejia 2009,
Introduction to Software Engineering
Slide 43
What are the attributes of good software?


Software should deliver the required functionality and
performance, and should be maintainable, dependable and usable
Maintainability
•

Dependability
•

Software should not waste system resources
Usability
•

Software must be trustworthy
Efficiency
•

Software must evolve to meet changing needs
Software must be usable by the users for which it was designed
There are many others!
©Sommerville 2000, Medvidovic 2006, Mejia 2009,
Introduction to Software Engineering
Slide 44
What are the key challenges facing
software engineering?

Coping with
•
•
•

Legacy systems
•

Old, valuable systems must be maintained and updated
Heterogeneity
•

Legacy systems
Increasing diversity
Demands for reduced delivery times
Systems are distributed and include a mix of hardware and software
Delivery
•
There is increasing pressure for faster delivery of software
©Sommerville 2000, Medvidovic 2006, Mejia 2009,
Introduction to Software Engineering
Slide 45
Essential software engineering
difficulties

Complexity
•
•

Conformity
•
•

software is always required to conform
often the “last kid on the block”
Changeability
•
•

no two software parts are alike
complexity grows non-linearly with size
software is viewed as infinitely malleable
change originates with new applications, users, machines, standards, laws
Invisibility
•
•
the reality of software is not embedded in space
software is not representable as a familiar geometric entity
©Sommerville 2000, Medvidovic 2006, Mejia 2009,
Introduction to Software Engineering
Slide 46
Key points




Software engineering is an engineering discipline which is concerned
with all aspects of software production.
Software products consist of developed programs and associated
documentation. Essential product attributes are maintainability,
dependability, efficiency and usability.
The software process consists of activities which are involved in
developing software products. Basic activities are software
specification, development, validation and evolution.
Methods are organised ways of producing software. They include
suggestions for the process to be followed, the notations to be used,
rules governing the system descriptions which are produced and
design guidelines.
©Sommerville 2000, Medvidovic 2006, Mejia 2009,
Introduction to Software Engineering
Slide 47