Overview of Software

Engineering Principles
CSCI 589:
Software Engineering for Embedded Systems

August 25, 2003
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
Software Engineering
The term is 35 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?
Many aspects have been made systematic
Methods/methodologies/techniques
Languages
Tools
Processes
Software Engineering in a
Nutshell
Development of software systems whose
size/complexity warrants team(s) of engineers
multi-person construction of multi-version software
[Parnas 1987]
Scope
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
Ever-Present Difficulties
Few guiding scientific principles
Few universally applicable methods
As much
managerial / psychological / sociological
as technological
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

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
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
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
Relative Costs of Fixing
Software Faults
Requirements Specification Planning Design Implementation Integration Maintenance
1
2
3
4
10
30
200
Mythical Man-Month
by Fred Brooks
Published in 1975, republished in 1995
Experience managing development of OS/360 in 1964-65
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
Conceptual integrity achieved through chief architect
Implementation achieved through well-managed effort
Brookss Law
Adding personnel to a late project makes it later
Software Development Lifecycle
Waterfall Model
Requirements
Design
Implementation
Integration
Validation
Deployment
Evaluate alternatives,
identify, resolve risks,
develop prototypes
Develop, verify
next-level product
Plan next phases
Determine objectives
alternatives, constraints
Software Development Lifecycle
Spiral Model
Requirements
Problem Definition Requirements Specification
determine exactly what the customer and user want
develop a contract with the customer
specifies what the software product is to do
Difficulties
client asks for wrong product
client is computer/software illiterate
specifications are ambiguous, inconsistent, incomplete
Architecture/Design
Requirements Specification Architecture/Design
architecture: decompose software into modules with
interfaces
design: develop module specifications (algorithms, data
types)
maintain a record of design decisions and traceability
specifies how the software product is to do its tasks
Difficulties
miscommunication between module designers
design may be inconsistent, incomplete, ambiguous
Architecture vs. Design
[Perry & Wolf 1992]
Architecture is concerned with the selection of
architectural elements, their interactions, and
the constraints on those elements and their
interactions necessary to provide a framework
in which to satisfy the requirements and serve
as a basis for the design.
Design is concerned with the modularization
and detailed interfaces of the design elements,
their algorithms and procedures, and the data
types needed to support the architecture and
to satisfy the requirements.
Implementation & Integration
Design Implementation
implement modules; verify that they meet their
specifications
combine modules according to the design
specifies how the software product does its tasks
Difficulties
module interaction errors
order of integration may influence quality and
productivity
Component-Based
Development
Develop generally applicable components of a
reasonable size and reuse them across
systems
Make sure they are adaptable to varying
contexts
Extend the idea beyond code to other
development artifacts
Question: what comes first?
Integration, then deployment
Deployment, then integration
Different Flavors of
Components
Third-party software pieces
Plug-ins / add-ins
Applets
Frameworks
Open Systems
Distributed object infrastructures
Compound documents
Legacy systems
Verification and Validation
Analysis
Static
Science
Formal verification
Informal reviews and walkthroughs
Testing
Dynamic
Engineering
White box vs. black box
Structural vs. behavioral
Issues of test adequacy

Deployment & Evolution
Operation Change
maintain software during/after user operation
determine whether the product still functions
correctly
Difficulties
rigid design
lack of documentation
personnel turnover
Configuration Management
(CM) [Tichy 1988]
CM is a discipline whose goal is to
control changes to large software
through the functions of
Component identification
Change tracking
Version selection and baselining
Software manufacture
Managing simultaneous updates (team
work)
CM in Action
1.1
1.2
1.4
2.0
2.1
2.2
3.1
3.0
1.5
4.0
1.0
1.3
Software Engineering
Principles
Rigor and formality
Separation of concerns
Modularity and decomposition
Abstraction
Anticipation of change
Generality
Incrementality
Scalability
Compositionality
Heterogeneity
From Principles to Tools
PRINCIPLES
METHODS AND
TECHNIQUES
METHODOLOGIES
TOOLS
Software Qualities
Qualities (a.k.a. ilities) are goals in the
practice of software engineering
External vs. Internal qualities
Product vs. Process qualities
External vs. Internal Qualities
External qualities are visible to the user
reliability, efficiency, usability
Internal qualities are the concern of
developers
they help developers achieve external
qualities
verifiability, maintainability, extensibility,
evolvability, adaptability
Product vs. Process Qualities
Product qualities concern the developed
artifacts
maintainability, understandability,
performance
Process qualities deal with the
development activity
products are developed through process
maintainability, productivity, timeliness
Some Software Qualities
Correctness
ideal quality
established w.r.t. the requirements specification
absolute
Reliability
statistical property
probability that software will operate as expected
over a given period of time
relative
Some Software Qualities
(cont.)
Robustness
reasonable behavior in unforeseen
circumstances
subjective
a specified requirement is an issue of correctness;
an unspecified requirement is an issue of
robustness
Usability
ability of end-users to easily use software
extremely subjective
Some Software Qualities
(cont.)
Understandability
ability of developers to easily understand
produced artifacts
internal product quality
subjective
Verifiability
ease of establishing desired properties
performed by formal analysis or testing
internal quality
Some Software Qualities
(cont.)
Performance
equated with efficiency
assessable by measurement, analysis, and
simulation
Evolvability
ability to add or modify functionality
addresses adaptive and perfective maintenance
problem: evolution of implementation is too easy
evolution should start at requirements or design
Some Software Qualities
(cont.)
Reusability
ability to construct new software from existing
pieces
must be planned for
occurs at all levels: from people to process, from
requirements to code
Interoperability
ability of software (sub)systems to cooperate with
others
easily integratable into larger systems
common techniques include APIs, plug-in
protocols, etc.
Some Software Qualities
(cont.)
Scalability
ability of a software system to grow in size
while maintaining its properties and
qualities
assumes maintainability and evolvability
goal of component-based development

Some Software Qualities
(cont.)
Heterogeneity
ability to compose a system from pieces developed in
multiple programming languages, on multiple platforms, by
multiple developers, etc.
necessitated by reuse
goal of component-based development
Portability
ability to execute in new environments with minimal effort
may be planned for by isolating environment-dependent
components
necessitated by the emergence of highly-distributed systems
(e.g., the Internet)
an aspect of heterogeneity
Software Process Qualities
Process is reliable if it consistently leads to high-
quality products
Process is robust if it can accommodate
unanticipated changes in tools and environments
Process performance is productivity
Process is evolvable if it can accommodate new
management and organizational techniques
Process is reusable if it can be applied across
projects and organizations
Assessing Software Qualities
Qualities must be measurable
Measurement requires that qualities be
precisely defined
Improvement requires accurate
measurement
Currently most qualities are informally
defined and are difficult to assess
Software Engineering
Axioms
Adding developers to a project will likely result in
further delays and accumulated costs
Basic tension of software engineering
better, cheaper, faster pick any two!
functionality, scalability, performance pick any two!
The longer a fault exists in software
the more costly it is to detect and correct
the less likely it is to be properly corrected
Up to 70% of all faults detected in large-scale software
projects are introduced in requirements and design
detecting the causes of those faults early may reduce their
resulting costs by a factor of 100 or more