Software Evolution

(1)

1

QuickTime™ and a TIFF (Uncompressed) decompressorare needed to see this picture.

Universidade Federal de Pernambuco - Centro de Informática

Lecture 10:

Software Evolution

⇐

Basics of Software Evolution

ªLaws of software evolution ªRequirements Growth

⇐

Basics of Change Management

ªBaselines, Change Requests and Configuration Management

⇐

Software Families - The product line approach

⇐

Requirements Traceability

ªImportance of traceability ªTraceability tools

Program Types

⇐

S-type Programs (“Specifiable”)

ªproblem can be stated formally and completely

ªacceptance: Is the program correct according to its specification?

ªThis software does not evolve.

¾A change to the specification defines a new problem, hence a new program

⇐

P-type Programs (“Problem-solving”)

ªimprecise statement of a real-world problem

ªacceptance: Is the program an acceptable solution to the problem?

ªThis software is likely to evolve continuously

¾because the solution is never perfect, and can be improved

¾because the real-world changes and hence the problem changes

⇐

E-type Programs (“Embedded”)

ªA system that becomes part of the world that it models ªacceptance: depends entirely on opinion and judgement ªThis software is inherently evolutionary

¾changes in the software and the world affect each other

Source: Adapted from Lehman 1980, pp1061-1063

(2)

2

worldreal

requirements specification PROGRAM

abstract view of world

solution compare

P-type

real world PROGRAM

abstract view of world requirements

specification

model

E-type formal

statement of problem

PROGRAM solution

worldreal

controls the production

of

provides maybe of

interest to relatemay

to

change change

change

S-type

Laws of Program Evolution

⇐

Continuing Change

ªAny software that reflects some external reality undergoes continual change or becomes progressively less useful

¾change continues until it is judged more cost effective to replace the system

⇐

Increasing Complexity

ªAs software evolves, its complexityincreases…

¾…unless steps are taken to control it.

⇐

Fundamental Law of Program Evolution

ªSoftware evolution is self-regulating

¾…with statistically determinable trends and invariants

⇐

Conservation of Organizational Stability

ªDuring the active life of a software system, the work output of a development project is roughly constant (regardless of resources!)

⇐

Conservation of Familiarity

ªThe amount of change in successive releases is roughly constant

(3)

3

Managing Requirements Change

⇐

Managers need to respond to requirements change

ªAdd new requirements during development

¾But not succumbing to feature creep ªModify requirements during development

¾Because development is a learning process ªRemove requirements during development

¾requirements “scrub” for handling cost/schedule slippage

⇐

Key techniques

ªChange Management Process ªRelease Planning

ªRequirements Prioritization ªRequirements Traceability ªArchitectural Stability

Change Management

⇐

Configuration Management

ªEach distinct product is a Configuration Item (CI) ªEach configuration item is placed under version control

ªControl which version of each CI belongs in which buildof the system

⇐

Baselines

ªA baselineis a stable version of a document or system

¾Safe to share among the team

ªFormal approval process for changes to be incorporated into the next baseline

⇐

Change Management Process

ªAll proposed changes are submitted formally as change requests ªA review boardreviews these periodically and decides which to accept

¾Review board also considers interaction between change requests

(4)

4

Towards Software Families

⇐

Libraries of Reusable Components

ªdomain specific libraries (e.g. Math libraries)

ªprogram development libraries (e.g. Java AWT, C libraries)

⇐

Domain Engineering

ªDivides software development into two parts:

¾domain analysis - identifies generic reusable components for a problem domain

¾application development - uses the domain components for specific applications.

⇐

Software Families

ªMany companies offer a range of related software systems

¾Choose a stable architecture for the software family

¾identify variations for different members of the family

ªRepresents a strategic business decision about what software to develop ªVertical families

¾e.g. ‘basic’, ‘deluxe’ and ‘pro’ versions of a system ªHorizontal families

¾similar systems used in related domains

Requirements Traceability

⇐

From IEEE-STD-830:

ªBackward traceability

¾i.e. to previous stages of development.

¾the origin of each requirement should be clear ªForward traceability

¾i.e., to all documents spawned by the SRS.

¾Facilitation of referencing of each requirement in future documentation

¾depends upon each requirement having a unique name or reference number.

⇐

From DOD-STD-2167A:

ªA requirements specification is traceable if:

(1) it contains or implements all applicable stipulations in predecessor document (2) a given term, acronym, or abbreviation means the same thing in all documents (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

document, that is, no untraceable material has been introduced (5) the two documents do not contradict one another

(5)

5

Source: Adapted from Palmer, 1996, p365

Importance of Traceability

⇐

Verification and Validation

ªassessing adequacy of test suite ªassessing conformance to

requirements

ªassessing completeness, consistency, impact analysis

ªassessing over- and under-design ªinvestigating high level behavior

impact on detailed specifications ªdetecting requirements conflicts ªchecking consistency of decision

making across the lifecycle

⇐

Maintenance

ªAssessing change requests ªTracing design rationale

⇐

Document access

ªability to find information quickly in large documents

⇐

Process visibility

ªability to see how the software was developed

ªprovides an audit trail

⇐

Management

ªchange management ªrisk management

ªcontrol of the development process

Traceability Difficulties

⇐

Cost

ªvery little automated support

ªfull traceability is very expensive and time-consuming

⇐

Delayed gratification

ªthe people defining traceability links are not the people who benefit from it

¾development vs. V&V

ªmuch of the benefit comes late in the lifecycle

¾testing, integration, maintenance

⇐

Size and diversity

ªHuge range of different document types, tools, decisions, responsibilities,…

ªNo common schema exists for classifying and cataloging these ªIn practice, traceability concentrates only on baselined requirements

Source: Adapted from Palmer, 1996, p365-6

(6)

6

Current Practice

⇐

Coverage:

ªlinks from requirements forward to designs, code, test cases, ªlinks back from designs, code, test cases to requirements ªlinks between requirements at different levels

⇐

Traceability process

ªAssign each sentence or paragraph a unique id number ªManually identify linkages

ªUse manual tables to record linkages in a document

ªUse a traceability tool (database) for project wide traceability ªTool then offers ability to

¾follow links

¾find missing links

¾measure overall traceability

Source: Adapted from Palmer, 1996, p367-8

Limitations of Current Tools

⇐

Informational Problems

ªTools fail to track usefultraceability information

¾e.g cannot answer queries such as “who is responsible for this piece of information?”

ªinadequate pre-requirements traceability

¾“where did this requirement come from?”

⇐

Lack of agreement…

ª…over the quantity and type of information to trace

⇐

Informal Communication

ªPeople attach great importance to personal contact and informal communication

¾These always supplement what is recorded in a traceability database ªBut then the traceability database only tells part of the story!

¾Even so, finding the appropriate people is a significant problem

Source: Adapted from Gotel & Finkelstein, 1993, p100

(7)

7

Source: Adapted from Gotel & Finkelstein, 1997, p100

Problematic Questions

⇐

Involvement

ªWho has been involved in the production of this requirement and how?

⇐

Responsibility & Remit

ªWho is responsible for this requirement?

ªWhat group has authority to make decisions about this requirement?

⇐

Change

ªWhat changes are relevant to this requirement?

¾Stakeholders’ changed jobs? changed development process?

¾When has responsibility for the requirement changed hands?

⇐

Notification

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

⇐

Loss of knowledge

ªWhat loss of project knowledge is likely if a specific individual leaves?

Summary

⇐

Software Evolution is inevitable

ªSoftware must evolve or become progressively less useful ªSoftware becomes more complex as it evolves

ªSoftware evolutions follows regular patterns

⇐

Good practice plans for evolution

ªRelease management

ªControlled requirements change process

⇐

Traceability needed to recover knowledge

ªBackwards to originating stakeholders ªForwards into design and implementation ªStill many questions traceability won’t answer