Introduction to Software Engineering
OVERVIEW
- The Software Process
- process models
- process modeling
- process improvement
- Requirements Capture
- Design
- system level
- module level
- data abstraction
- object-oriented methods
- Programming, Implementation
- Project Management
- planning and estimation
- risk assessent and risk management
- Testing, theory and practice
- Formal Specifications
- Verification
- proof based (axiomatic, functional)
- automatable
- Automation
- Computer Aided Software Engineering (CASE)
- Tools and SE Environments
- Many of you have practical experience developing systems in
an industrial setting.
- Many of the phases of the development process are handled informally,
that is, with English documents and apprenticeship experience.
- Very few development shops today use formal methods.
- We will concentrate on formal methods, since they are not familiar
from experience.
- Formal methods can help clarify the necessary thinking that goes
into a quality software product.
- Formal methods: supported, not imposed
The text is a good one for introducing the phases
of development without sinking into too great of a
survey mentality.
We will read a large percentage of the text.
For topics not covered, or not covered in enough
detail, we will consult papers from the computing
literature. A reading list is in your syllabus.
Topics from the Literature
- program verification
- C.A.R. Hoare (axiomatic)
- H. Mills (functional)
- formal specifications
- J. Guttag (ADTs and behavior axioms)
- D. Parnas (module traces)
- place/transition nets
- T. Murata (basic theory)
- J. Peterson (modeling examples)
- Cleanroom development
- H. Mills (basic theory)
- R. Selby and V. Basili (evaluation)
- SOFTWARE SYSTEM DEVELOPMENT
- We are building a product
- We use a process to achive this goal
- We use tools to support the process
- PRODUCT
Our target software system; often the software is part of some larger system
- phone network: wires, switches, satellites, software
- requirement: "dial tone in 1/2 second"
- combination of hardware and software needed
- systems engineering must be done; software engineer must be
part of that team
- PROCESS
How we get there
- LIFE CYCLE phases
- planning (staff, budget, equipment, etc...)
- requirements: users + engineers, face to face
- design: system, module
- implementation
- testing
- acceptance
- maintenance
- basic processes are adapted
- waterfall
- iterative prototyping
- exploratory development
- spiral
- SUPPORT TOOLS
How we manage the complexity
- subject to change
- as tool technology improves
- as new approaches are validated
- Specification notations
- Programming languages
- CASE
- Environments
History of Software Engineering
- term first used at a 1968 NATO workshop in West Germany
- focused on growing "software crisis"
- high development costs
- difficult management
- poor reliability
- lack of user acceptance
- impossible to maintain
- not many differences today from 1968 ...
Some Interesting Statistics
- U.S. software costs
- $50 billion in 1977
- > $100 billion in 1990
- costs seem to increase 10% to 15% per year
- software is > 10% of DoD budget
- recent Apple/Microsoft deal... MS Office for Mac is
$1 Billion business annually
- Gloal software statistics (older numbers, c.1989, pre-Web)
- China, India, former USSR... ???
Software Developement is Hard to Manage... Why?
- in a word, complexity
- software is, by far, the most complex artifact humans have created
- example: B1 bomber
- 1.3 million LOC airborne system
- 6.0 million LOC ground support systems
- common for systems to have 1000's of modules, much bigger not uncommon
- relationships among elements in a system are not constrained by
spatial geometry like in physical engineering systems
Reliability
- each release of OS/360 had > 1000 errors
- USS Vincenes/Iranian Airliner incident
- AEGIS was hot new product, the best
- first shuttle launch
- aborted due to timing errors
- Mars rover
- bad user commands, stuck it on a rock
- MIR spacestation
- bad programming was admitted this week as source
of some failures
- Hubble Space Telescope
- specification error (not software)
- list of examples is nearly endless ...
WHAT IS SOFTWARE?
A very broad term... the product includes
- code
- source
- binaries
- versions (groups)
- requirements specifications
- design specifications
- test cases and results
- management documentation
- documents for users
- reports for maintainers
WHAT IS THE GOAL OF SOFTWARE ENGINEERING?
- finite resources (predicted levels)
- means costs
- much of cost incurred after initial development
- maintainablity is one of the best cost savers
- limited time (schedule)
- contract deadlines
- competition
- technology obsolescence
- quality product
- must work within all these constraints
WHAT MAKES A QUALITY PRODUCT?
- attributes of software can be either
- internal: meaningful to developers
- external: meaningful to users
- attributes can apply to either
- product: the tangibles and deliverables
- process: methods and techniques
- many attributes overlap these catagories
- correct
- code functionality agrees with specifications
- reliable
- does not fail during execution (even if not correct)
- robust
- gracefully handles unexpected inputs, i.e., inputs not covered
by specifications (a requirements flaw?)
- means low cost to maintain
- maintainable
- long use system will/must change
- design and build for easy change
- verifiable
- can we show that the qualities of performance,
correctness, etc., exist in the system?
- reusable
- is the design modular, well documented, so components can
be employed in new system with less effort than required
for re-development?
- portable
- easy to get operational in new environments
- interoperable
- open system; can the software employ the work
or products of other systems?
- performance
- minimax problem in efficiency... need maximum performance
(speed, memory use...) with minimum maintenance... these are linked!
- productivity, when used for process
- user interface
- match capablities of audience with system functionality
- client/server systems are proving good design will have example
from current research
These are suggestive, but in no way exhaustive.
- information systems
- data abstraction, modularity are keys
- transaction based, object-oriented
- performance at user interface
- real-time systems
- performance requirements more stringent
- correctness often critical
- distributed systems
- interoperability very important
- robustness, fault-tolerance
- embedded systems
- hardware/software combinations
- minimal user interface considerations