University of Toronto Department of Computer Science University of Toronto Department of Computer Science

Lecture 21: Program Types

Software Evolution
Source: Adapted from Lehman 1980, pp1061-1063

Ü S-type Programs (“Specifiable”)

Ä problem can be stated formally and completely
Ä acceptance: Is the program correct according to its specification?
Ü Basics of Software Evolution Ä This software does not evolve.
Ä Laws of software evolution Ø A change to the specification defines a new problem, hence a new program
Ä Requirements Growth
Ä Software Aging Ü P-type Programs (“Problem-solving”)
Ä imprecise statement of a real-world problem
Ü Basics of Change Management Ä acceptance: Is the program an acceptable solution to the problem?
Ä Baselines, Change Requests and Configuration Management Ä This software is likely to evolve continuously
Ø because the solution is never perfect, and can be improved
Ü Software Families - The product line approach Ø because the real-world changes and hence the problem changes

Ü Requirements Traceability Ü E-type Programs (“Embedded”)

Ä Importance of traceability Ä A system that becomes part of the world that it models
Ä Traceability tools Ä acceptance: depends entirely on opinion and judgement
Ä This software is inherently evolutionary
Ø changes in the software and the world affect each other

© Easterbrook 2004 1 © Easterbrook 2004 2

University of Toronto Department of Computer Science University of Toronto Department of Computer Science

Laws of Program Evolution

Source: Adapted from Lehman 1980, pp1061-1063

formal
may statement controls the Source: Adapted from Lehman 1980, pp1061-1063
relate production
to
of problem
of real
P-type
Ü Continuing Change
change
world Ä Any software that reflects some external reality undergoes continual change
real PROGRAM or becomes progressively less useful
world abstract Ø change continues until it is judged more cost effective to replace the system

provides
view of world Ü Increasing Complexity
maybe of solution Ä As software evolves, its complexity increases…
interest to compare change Ø …unless steps are taken to control it.
S-type requirements
specification Ü Fundamental Law of Program Evolution
E-type Ä Software evolution is self-regulating
Ø …with statistically determinable trends and invariants
real world
change solution PROGRAM Ü Conservation of Organizational Stability
PROGRAM Ä During the active life of a software system, the work output of a
development project is roughly constant (regardless of resources!)

requirements
abstract Ü Conservation of Familiarity
view of world
specification Ä The amount of change in successive releases is roughly constant

model

© Easterbrook 2004 3 © Easterbrook 2004 4

1
 University of Toronto Department of Computer Science University of Toronto Department of Computer Science

Requirements Growth
Source: Adapted from Davis 1988, pp1453-1455
Alternative lifecycle models
Source: Adapted from Davis 1988, pp1455-1459
Throwaway Prototyping Evolutionary Prototyping

Functionality

Functionality
Ü Davis’s model: User needs User needs
ÄUser needs evolve continuously conventional
Ø Imagine a graph showing growth development

Functionality
of needs over time User needs
Ø May not be linear or continuous
(hence no scale shown)
ÄTraditional development always Inappropriateness
lags behind needs growth
(shaded area)
Ø first release implements only
part of the original requirements Shortfall Time Time
Ø functional enhancement adds new
functionality Incremental Development Automated Software Synthesis
Adaptability

Functionality

Functionality
Ø eventually, further enhancement Lateness User needs
becomes too costly, and a User needs
(slope of line)
replacement is planned Longevity
Ø the replacement also only
implements part of its
requirements, Time
Ø and so on... ts e ed e
en se as ce iver as
em lea ph pla el ph
quir t re ent re nt d ent
re s em d em
fir nc an me nc
ify ha ze ce ha
nt en ee pla en Time
ide fr re Time
© Easterbrook 2004 5 © Easterbrook 2004 6

University of Toronto Department of Computer Science University of Toronto Department of Computer Science

Software “maintenance” Software Aging

Source: Adapted from Blum, 1992, p492-495 Source: Adapted from Parnas, 1994

Ü Maintenance philosophies Ü Causes of Software Aging

Ä “throw-it-over-the-wall” - someone else is responsible for maintenance Ä Failure to update the software to meet changing needs
Ø investment in knowledge and experience is lost Ø Customers switch to a new product if benefits outweigh switching costs
Ø maintenance becomes a reverse engineering challenge Ä Changes to software tend to reduce its coherence
Ä “mission orientation” - development team make a long term commitment to
maintaining/enhancing the software Ü Costs of Software Aging
Ä Owners of aging software find it hard to keep up with the marketplace
Ü Basili’s maintenance process models: Ä Deterioration in space/time performance due to deteriorating structure
Ä Quick-fix model Ä Aging software gets more buggy
Ø changes made at the code level, as easily as possible Ø Each “bug fix” introduces more errors than it fixes
Ø rapidly degrades the structure of the software
Ä Iterative enhancement model Ü Ways of Increasing Longevity
Ø Changes made based on an analysis of the existing system
Ø attempts to control complexity and maintain good design
Ä Design for change
Ä Full-reuse model Ä Document the software carefully
Ø Starts with requirements for the new system, reusing as much as possible Ä Requirements and designs should be reviewed by those responsible for its
Ø Needs a mature reuse culture to be successful maintenance
Ä Software Rejuvenation…

© Easterbrook 2004 7 © Easterbrook 2004 8

2
 University of Toronto Department of Computer Science University of Toronto Department of Computer Science

Managing Requirements Change Change Management

Ü Managers need to respond to requirements change Ü Configuration Management
Ä Add new requirements during development Ä Each distinct product is a Configuration Item (CI)
Ø But not succumbing to feature creep Ä Each configuration item is placed under version control
Ä Modify requirements during development Ä Control which version of each CI belongs in which build of the system
Ø Because development is a learning process
Ä Remove requirements during development Ü Baselines
Ø requirements “scrub” for handling cost/schedule slippage
Ä A baseline is a stable version of a document or system
Ü Key techniques Ø Safe to share among the team
Ä Formal approval process for changes to be incorporated into the next
Ä Change Management Process baseline
Ä Release Planning
Ä Requirements Prioritization (previous lecture!) Ü Change Management Process
Ä Requirements Traceability Ä All proposed changes are submitted formally as change requests
Ä Architectural Stability (next week’s lecture) Ä A review board reviews these periodically and decides which to accept
Ø Review board also considers interaction between change requests

© Easterbrook 2004 9 © Easterbrook 2004 10

University of Toronto Department of Computer Science University of Toronto Department of Computer Science

Towards Software Families Requirements Traceability

Ü Libraries of Reusable Components Ü From IEEE-STD-830:
Ä domain specific libraries (e.g. Math libraries) Ä Backward traceability
Ä program development libraries (e.g. Java AWT, C libraries) Ø i.e. to previous stages of development.
Ø the origin of each requirement should be clear
Ü Domain Engineering Ä Forward traceability
Ä Divides software development into two parts: Ø i.e., to all documents spawned by the SRS.
Ø domain analysis - identifies generic reusable components for a problem domain Ø Facilitation of referencing of each requirement in future documentation
Ø application development - uses the domain components for specific applications. Ø depends upon each requirement having a unique name or reference number.

Ü Software Families Ü From DOD-STD-2167A:

Ä Many companies offer a range of related software systems Ä A requirements specification is traceable if:
Ø Choose a stable architecture for the software family Ø “(1) it contains or implements all applicable stipulations in predecessor document
Ø identify variations for different members of the family Ø (2) a given term, acronym, or abbreviation means the same thing in all documents
Ä Represents a strategic business decision about what software to develop Ø (3) a given item or concept is referred to by the same name in the documents
Ø (4) all material in the successor document has its basis in the predecessor
Ä Vertical families document, that is, no untraceable material has been introduced
Ø e.g. ‘basic’, ‘deluxe’ and ‘pro’ versions of a system Ø (5) the two documents do not contradict one another”
Ä Horizontal families
Ø similar systems used in related domains

© Easterbrook 2004 11 © Easterbrook 2004 12

3
 University of Toronto Department of Computer Science University of Toronto Department of Computer Science

Importance of Traceability Traceability Difficulties

Ü Verification and Validation Ü Document access Ü Cost
Ä assessing adequacy of test suite Ä ability to find information quickly in Ä very little automated support
Ä assessing conformance to large documents
requirements
Ä full traceability is very expensive and time-consuming
Ü Process visibility
Ä assessing completeness, consistency,
impact analysis Ä ability to see how the software was Ü Delayed gratification
Ä assessing over- and under-design developed Ä the people defining traceability links are not the people who benefit from it
Ä investigating high level behavior Ä provides an audit trail Ø development vs. V&V
impact on detailed specifications
Ü Management Ä much of the benefit comes late in the lifecycle
Ä detecting requirements conflicts Ø testing, integration, maintenance
Ä change management
Ä checking consistency of decision
making across the lifecycle
Ä risk management
Ä control of the development process
Ü Size and diversity
Ü Maintenance Ä Huge range of different document types, tools, decisions, responsibilities,…
Ä Assessing change requests Ä No common schema exists for classifying and cataloging these
Ä Tracing design rationale Ä In practice, traceability concentrates only on baselined requirements

© Easterbrook 2004
Source: Adapted from Palmer, 1996, p365 13 © Easterbrook 2004
Source: Adapted from Palmer, 1996, p365-6 14

University of Toronto Department of Computer Science University of Toronto Department of Computer Science

Current Practice Limitations of Current Tools

Ü Coverage: Ü Informational Problems
Ä links from requirements forward to designs, code, test cases, Ä Tools fail to track useful traceability information
Ä links back from designs, code, test cases to requirements Ø e.g cannot answer queries such as “who is responsible for this piece of
information?”
Ä links between requirements at different levels
Ä inadequate pre-requirements traceability
Ü Traceability process Ø “where did this requirement come from?”

Ä Assign each sentence or paragraph a unique id number Ü Lack of agreement…

Ä Manually identify linkages Ä …over the quantity and type of information to trace
Ä Use manual tables to record linkages in a document
Ä Use a traceability tool (database) for project wide traceability Ü Informal Communication
Ä Tool then offers ability to Ä People attach great importance to personal contact and informal
Ø follow links communication
Ø find missing links Ø These always supplement what is recorded in a traceability database
Ø measure overall traceability
Ä But then the traceability database only tells part of the story!
Ø Even so, finding the appropriate people is a significant problem

© Easterbrook 2004
Source: Adapted from Palmer, 1996, p367-8 15 © Easterbrook 2004
Source: Adapted from Gotel & Finkelstein, 1993, p100 16

4
 University of Toronto Department of Computer Science

Problematic Questions
Ü Involvement
Ä Who has been involved in the production of this requirement and how?

Ü Responsibility & Remit

Ä Who is responsible for this requirement?
Ø who is currently responsible for it?
Ø at what points in its life has this responsibility changed hands?
Ä Within which group’s remit are decisions about this requirement?

Ü Change
Ä At what points in the life of this requirements has working arrangements of
all involved been changed?

Ü Notification
Ä Who needs to be involved in, or informed of, any changes proposed to this
requirement?

Ü Loss of knowledge
Ä What are the ramifications regarding the loss of project knowledge if a
specific individual or group leaves?

© Easterbrook 2004
Source: Adapted from Gotel & Finkelstein, 1997, p100 17