April 17, 2014CS410 – Software Engineering Lecture #18: Rationale Management 1 Software Projects You need to deliver the following things: Project Agreement

April 17, 2014 CS410 – Software Engineering Lecture #18: Rationale Management

1

Software Projects

You need to deliver the following things:

• Project Agreement (already completed)• Documentation• Code• Demonstration for Client• Presentation in Class


2

Software Projects

Documentation:

• Describes the capabilities of the software product• Explains to the end user how to use the software• Describes to other developers the most important

classes, their members and methods.• Due by May 14.• It is recommended to write at least a rough draft

of the documentation before writing the code.


3

Software Projects

Code:

• Programming language: C++• Operating system: Linux (software must be

demonstrated on campus)• Object-oriented design• Comments• Due by May 14 (e-mail)


4

Software Projects

Demonstration for Client:

• Demonstration in Unix Lab, PC Lab, Visual Attention Lab or client’s office

• Can be done on a team member’s laptop• Customer will play around with the software and

try to crash it• Code review: Every project participant will be

asked questions about her/his code and why she/he chose that particular implementation.

• Due by May 14


5

Software Projects

Presentation in Class:

• Duration for each team’s presentation: 20 minutes• Every team member has to speak• One person (team leader) provides overview of the

system• Others present their part of the system, algorithms

and data structures they used, issues they encountered, how they were resolved, etc.

• Will take place on May 1, 6, and 8.


6

Software Projects

Rules:

• Each team member must implement a clearly defined part of the software.

• No re-use of any code unless explicitly allowed by the customer.

• It is recommended to schedule at least one meeting with the customer during the development process.

• Team members will evaluate each other after project completion.


7

Rationale Management

Rationale:•What is it?•Why should you care?

Rationale methods:•Representing rationale•Authoring rationale•Accessing rationale

State of practice & research

Summary


8

An Aircraft ExampleA320:• First fly-by-wire passenger aircraft• 150 seats, short to medium haul

A319 & A321:• Derivatives of A320• Same handling as A320

Rationale: • Reduce pilot training & maintenance costs• Increase flexibility for airline


9

An Aircraft Example

A330 & A340:• Long haul and ultra long haul• 2x seats, 3x range• Similar handling as A320 family

Rationale:• With minimum cross training, A320 pilots can be

certified to fly A330 and A340 airplanes

Consequence:• Any change in these five airplanes must maintain

this similarity


10

What is Rationale?

Rationale is the reasoning that lead to the system.

Rationale includes:

Issues that were addressed,

Alternatives that were considered,

Decisions that were made to resolve the issues,

Criteria that were used to guide decisions, and

Debate developers went through to reach a decision.


11

Why Rationale?

Software systems are similar to passenger airplanes:

They result from a large number of decisions taken over an extended period of time.

• Evolving assumptions• Legacy decisions• Conflicting criteria

Þ High maintenance costÞ Loss & rediscovery of information


12

Rationale Helps Deal with Change

Improve maintenance support:• Provide maintainers with design context

Improve learning:• New staff can learn the design by replaying the

decisions that produced it

Improve analysis and design:• Avoid duplicate evaluation of poor alternatives• Make consistent and explicit trade-off


13

Levels of Rationale

No rationale captured:• Rationale is only present in memos, online communication,

developers’ memory

Rationale reconstruction:• Rationale is documented in a document justifying the final

design

Rationale capture:• Rationale is documented during design as it is developed

Rationale integration:• Rationale drives the design


14

Example: Centralized Traffic Control

• CTC systems enable dispatchers to monitor and control trains remotely,

• CTC allows the planning of routes and re-planning in case of problems.

T1291>

<T1515

Track circuits

Switches

Trains

Signals

S1

S2

S3

SW1 SW2

S4


15

Centralized Traffic Control

CTC systems are ideal examples of rationale capture:

Long lived systems (some systems include relays installed last century)

•Extended maintenance life cycle

Downtime is expensive (although not safety critical)•Low tolerance for bugs•Transition to mature technology

Initial developers are not available


16

input?:Issuedisplay?:Issue

Issues

• Issues are concrete problems which usually do not have a unique, correct solution.

• Issues are phrased as questions.

How should track sections be displayed?

How should the dispatcher input commands?


17

Proposals• Proposals are possible alternatives to issues.• One proposal can be shared across multiple issues.


addressed by

text-based:Proposal

addressed byaddressed by

point&click:Proposal

The interface for the dispatcher could be realized with a point & click interface.

The display used by the dispatcher can be a text only display with graphic

characters to represent track segments.


18

Consequent Issues• Consequent issues are issues raised by the

introduction of a proposal.

terminal?:Issue

raises

Which terminal emulation should be used for the display?


addressed by

text-based:Proposal




19

Criteria• A criterion represent a goodness measure.• Criteria are often design goals or nonfunctional

requirements.

availability$:Criterionusability$:Criterion

fails fails

The time to input commands should be less than two seconds.

The CTC system should have at least a 99% availability.

terminal?:Issue

raises


addressed by

text-based:Proposal



meets meets


20

Arguments

• Arguments represent the debate developers went through to arrive to resolve the issue.

• Arguments can support or oppose any other part of the rationale.

• Arguments constitute the largest part of the rationale.


21

Arguments

availability-first!:Argument

is supported by

is opposed by

Point&click interfaces are more complex to implement than text-based interfaces. Hence, they are also more difficult to test. The point&click interface risks introducing fatal errors in the

system that would offset any usability benefit the interface would provide.


fails failsterminal?:Issue

raises


addressed by

text-based:Proposal



meets meets


22

Resolutions

• Resolutions represent decisions.• A resolution summarizes the selected alternative and

the supporting argument.• A resolved issue is said to be closed.• A resolved issue can be re-opened if necessary, in

which case the resolution is demoted.


23

Resolutionstext-based&keyboard

:Resolution

resolvesresolves

availability-first!:Argument

is supported by

is opposed by


fails failsterminal?:Issue

raises


addressed by

text-based:Proposal



meets meets


24

Representing Rationale: Issue Models

Proposal Criterion$

Issue?

meets +

fails -

is a consequence

responds

Argument!

supports +objects to -

supports +objects to -

Resolution.

resolves


25

Representing Rationale

Many issue models have been proposed:• IBIS, QOC, DRL, WinWin• Similar in their essence• Differ in the amount of detail that can be captured

Challenges:• Require tool support for capture and access• Require integration with project management tools• Require integration with methodology


26

Authoring Rationale

Approaches:• Reconstruction• Record-and-replay• Byproduct of development methodology

Challenges:• Lot of information to capture• Disruptive for developers• Formalizing knowledge is expensive


27

Accessing RationaleBrowse & search:• Full text search allows to identify interesting nodes• Issue model links allow the browsing of related

issues quickly

Passive & active design critique:• Rationale can be used by knowledge based critiques

to evaluate a design

Challenges:• Evolving terminology• Navigation through a large flat space


28

State of the Practice

Standalone issue based tools:• QuestMap

Problem management tools:• Work flow application tracking problems and resolutions• Integrated with configuration management• Some tools (e.g., ClearQuest) allow schema to be

customized

RequisitePro:• Requirements management• Integrated with configuration management• Explicitly captures rationale behind change


29

An example of issue database (LN IBIS database template in Domino Lotus Notes).


30

State of Research

Many solutions for representation exist and can be tailored to a specific problem.

Progress in natural language search and in hypertext technology make access a less critical issue.

Current challenges:•Integration with methodology•Integration with tools•Overhead


31

Open Issues

Formalizing knowledge is costly:• Maintaining a consistent design model is expensive.• Capturing and maintaining its rationale is worse.

The benefits of rationale are not perceived by current developers:• If the person who does the work is not the one who benefits

from it, the work will have lower priority.• 40-90% of off-the-shelf software projects are terminated

before the product ships.

Capturing rationale is usually disruptive.

Current approaches do not scale to real problems.


32

Why Software Configuration Management?The problem:• Multiple people have to work on software that is changing• More than one version of the software has to be supported:

Released systems Custom configured systems (different functionality) System(s) under development

• Software must run on different machines and operating systems

Need for coordination

Software Configuration Management • manages evolving software systems• controls the costs involved in making changes to a system


33

What is Software Configuration Management?

Definition: • A set of management disciplines within the software

engineering process to develop a baseline.

Description:• Software Configuration Management encompasses the

disciplines and techniques of initiating, evaluating and controlling change to software products during and after the software engineering process.

Standards (approved by ANSI):• IEEE 828: Software Configuration Management Plans• IEEE 1042: Guide to Software Configuration Management


34

SCM ActivitiesConfiguration item identification

•is the modeling of the system as a set of evolving components

Promotion management•is the creation of versions for other developers

Release management•is the creation of versions for the clients and users

Branch management•is the management of concurrent development

Variant management•is the management of versions intended to coexist

Change management •is the handling, approval and tracking of change requests


35

SCM RolesConfiguration Manager:• Responsible for identifying configuration items. The

configuration manager can also be responsible for defining the procedures for creating promotions and releases

Change control board member:• Responsible for approving or rejecting change requests

Developer:• Creates promotions triggered by change requests or the

normal activities of development. The developer checks in changes and resolves conflicts

Auditor:• Responsible for the selection and evaluation of promotions

for release and for ensuring the consistency and completeness of this release


36

Terminology and Methodology

What are•Configuration Items,•Baselines,•SCM Directories,•Versions, Revisions and Releases?

The usage of the terminology presented here is not strict but varies for different configuration management systems.


37

Terminology: Configuration Item

“An aggregation of hardware, software, or both, that is designated for configuration management and treated as a single entity in the configuration management process.”

Software configuration items are not only program code segments but all type of documents that are produced during development, e.g.:

• all types of code files• drivers for tests• analysis or design documents• user or developer manuals• system configurations (e.g. version of compiler used)

In some systems, not only software but also hardware configuration items (CPUs, bus speed frequencies) exist!


38

Terminology: Baseline

“A specification or product that has been formally reviewed and agreed to by responsible management, that thereafter serves as the basis for further development, and can be changed only through formal change control procedures.”

Examples:

• Baseline A: The API of a program is completely defined; the bodies of the methods are empty.

• Baseline B: All data access methods are implemented and tested; programming of the GUI can start.

• Baseline C: GUI is implemented, test-phase can start.


39

More on Baselines

Many naming schemes for baselines exist (1.0, 6.01a, ...).

3 digit scheme:

Release (Customer)

Version (Developer)

Revision (Developer)

7.5.5


40

Baselines in SCM

Official Release

Baseline A (developmental)

Baseline B (functional)

Baseline C (beta test)

All changes relative to baseline A

All changes relative to baseline B

All changes relative to baseline C


41

Foo’95 Foo’98

Standard SCM Directories

Programmer’s Directory • (IEEE Std: “Dynamic Library”)• Completely under control of one

programmer.

Central sourcecode archive

Release

PromotionMaster Directory • (IEEE Std: “Controlled Library”) • Central directory of all

promotions.

Software Repository• (IEEE Std: “Static Library”)• Externally released baselines.


42

Change Management

Change management is the handling of change requests.• A change request leads to the creation of a new release.

General change process:• The change is requested (this can be done by anyone

including users and developers).• The change request is assessed against project goals.• Following the assessment, the change is accepted or

rejected.• If it is accepted, the change is assigned to a developer and

implemented.• The implemented change is audited.


43

Change Management

The complexity of the change management process varies with the project:

• Small projects can perform change requests informally and fast.• Complex projects require detailed change request

forms and the official approval by one or more managers.


44

Two types of controlling change:• Promotion: The internal development state of a

software is changed.• Release: A set of promotions is distributed outside

the development organization.

Controlling Changes

User

Promotion

PromotePolicy

ProgrammerRelease

ReleasePolicy

Software RepositoryMasterDirectory


45

Approaches for controlling change to libraries (Change Policies):

•Informal (good for research type environments)•Formal approach (good for externally developed

CIs and for releases)

Change Policies


46

Change Policies• Whenever a promotion or a release is performed, one or more

policies apply. • The purpose of change policies is to guarantee that each

version, revision or release (see next slide) conforms to commonly accepted criteria.

Examples for change policies:

• “No developer is allowed to promote source code which cannot be compiled without errors and warnings.”

• “No baseline can be released without having been beta-tested by at least 500 external persons.”


47

Version vs. Revision vs. Release Version: • An initial release or re-release of a configuration item

associated with a complete compilation or recompilation of the item. Different versions have different functionality.

Revision: • Change to a version that corrects only errors in the

design/code, but does not affect the documented functionality.

Release: • The formal distribution of an approved version.


48

Tools for SCMSoftware configuration management is normally supported by tools with different functionality.

Examples:

•RCS: very old but still in use; only version control system

•CVS: based on RCS, allows concurrent working without locking

•Perforce: repository server; keeps track of developer’s activities

•ClearCase: multiple servers, process modeling, policy check mechanisms


49

SCMP following the IEEE 828-1990 standard

Tasks for the Configuration Managers

Define configuration itemsDefine configuration items

Define promote /release policiesDefine promote /release policies

Define responsibilitiesDefine responsibilities

Set up configuration management systemSet up configuration management system

Documents

April 17, 2014CS410 – Software Engineering Lecture #18: Rationale Management 1 Software Projects You need to deliver the following things: Project Agreement