Trustworthy Transparency and Lean Traceability

COMPSAC 2006 Chicago, IL, September 17-21, 2OO6
30th Annual International Computer Software & Applications Conference
Trustworthy Transparency
& Lean Traceability
20 September 2006
Brad Appleton
Software CM/ALM Solution Architect
Arlington Heights, IL
brad@bradapp.net

2
Traceability: The Agile CM Perspective
• 7 “Wastes” of Software Development
• 6 Facets of Traceability (4+2 SCM/ALM Views)
• Software as Knowledge
• 5 Orders of Ignorance & Traceability
• 4 Values of Agility & Rings of Visibility
• 3 Driving Forces for Traceability
• 2 Overarching Objectives of Traceability
• 1 Ultimate Goal: Trust-ability
• Trustworthy Transparency & Lean Traceability
Trustworthy Transparency & Lean TraceabilityBrad Appleton

3
7 “Wastes” of Software Development
1. Extra/Unused features (Overproduction)
2. Partially developed work not released to production
(Inventory)
3. Intermediate/unused artifacts (Extra Processing)
4. Seeking Information (Motion)
5. Escaped defects not caught by tests/reviews
(Defects)
6. Waiting (including Customer Waiting)
7. Handoffs (Transportation)
Source: Mary & Tom Poppendieck, http://www.poppendieck.com

4
6 Facets of Traceability
1. Change Impact/Dependency Analysis
2. Product Conformance
3. Process Compliance
4. Project Accountability
– safeguard against unauthorized change and “gold plating”
5. Baseline Reproducibility
– so "all the king's horses and all the king's men" can put your
fallen "humpty-dumpty" build back together again
6. Organizational Learning
– "know-why" you did what you did when you did it

5
4+2 Views of SCM/ALM Architecture
Organization Management
Teaming & Collaboration
Producers & Consumers
Metrics/Reports/Audits
PhysicalConceptual
ContentContext
decision binding-time &
change/creation time
diversity
& scale
Project
Project/Program Managers, QA/V&V
Status Accounting
Request/Defect Management
Change Planning/Tracking
CR
CR
CR
Environment
IT Engineering/Support
Workspaces/Repositories
Application Integration
Computing Infrastructure
Evolution
Integrators/Release Mgrs
Versioning/Baselining
Branching & Merging
Parallel Development
Product
Architects/Engineers/Builders
Product/Artifact Structure
Build/Release Engineering
change/creation-time
& decision binding-time
scale &
diversity
Copyright©1997-2006byBradAppleton
Process
Process-users/engineers
Process Workflow
Procedures/Training
Practices/Patterns
(Who)
(What)
(When) (Where)
(Why)
(How)

6
Software as Knowledge (Armour)
• “Software is not a product! It is a medium
for storing executable knowledge.”
• Therefore, software development is a
knowledge creating activity. …
• Or equivalently, software development is
an ignorance reduction activity
-- Phil Armour, The Laws of Software Process

7
5 Orders of Ignorance (Armour)
0th Order Ignorance (0OI) – Lack of Ignorance: I know
something
1st Order Ignorance (1OI) – Lack of Knowledge: I don’t
know something
2nd Order Ignorance (2OI) – Lack of Awareness: I don’t
know that I don’t know something
3rd Order Ignorance (30I) – Lack of Process: I don’t know
of a suitably efficient or systematic way to find out that I
don’t know that I don’t know something
4th Order Ignorance (40I) – Meta Ignorance: I don’t know
about the Five Orders of Ignorance

8
5 Orders of Traceability (Appleton)
0th Order Traceability – Existence:
– Tracking Knowledge Content
1st Order Traceability – Structure:
– Tracking Knowledge Composition
2nd Order Traceability – History:
– Tracking Knowledge Context
3rd Order Traceability – Transformation:
– Tracking Knowledge Creation (“rich traceability” &
causal connections)
4th Order Traceability – Meta-Traceability

9
4 Fundamental Values of Agility
1. Individuals and interactions over processes and
tools
2. Working software over comprehensive
documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan
There is value in the items on the right
• but value the items on the left more!
• (“over” != “instead of”)
Source: The Agile Manifesto, http://www.agilemanifesto.org

10
4 Rings of Stakeholder Visibility
-- Roger Sessions

11
3 Driving Forces for Traceability
1. Organizational Boundaries
– More layers of organizational hierarchy means less
direct visibility to governing decision-makers
– Less visibility into a project decreases trust (people
often distrust what they cannot see).
2. Feedback Cycle-time
– Trust decreases as more time passes between the
request/start of work, and evidence of its progress
3. Knowledge Complexity
– The more complex something is, the less
confidence I have that it does what I expect.

12
2 Overarching Objectives for Traceability
1. Transparency:
– the ability to readily view all the information we are
concerned with, and then …
2. Identification:
– the ability to identify our concerns so we can
separate independent sets of concerns and
cohesively associate the related ones.
 Transparency resolves the issue of visibility.
 Information structure organizes and identifies
the set of concerns to track and navigate.

13
Trustworthy Transparency
“The age of trustworthy transparency in software engineering
is upon us. Trustworthy transparency changes the culture
in an organization and enables change that unleashes
significant gains in productivity and initial quality.”
“However, transparency and managing based on objective
study of reality strains existing software engineering
culture as all the old rules, obfuscation, economies of
truth, wishful thinking and subjective decision making
must be cast aside. What can you expect, how will you
cope and how can you harness the power of trustworthy
transparency in your organization?”
-- David J. Anderson

14
Achieving Agility
Responding quickly & effectively to change
requires minimizing:
• The cost of knowledge-transfer
• The cost of knowledge capture (documents!)
• The time between making a decision, and exploring its
results to learn the consequences of implementing it
Close collaboration & frequent iteration -- critical for success!

15
Principles of Lean Development
• Eliminate Waste (Minimize Artifacts & Add Nothing but
Value)
• Build Quality In (Satisfy All Stakeholders & Deploy
Comprehensive Testing)
• Amplify Learning (Learn by Experimentation)
• Defer Commitment (Decide as Late as Possible)
• Deliver Fast (Deliver as Fast as Possible)
• Respect People (Decide as Low as Possible)
• Optimize the “Whole” (Measure Business Impact &
Optimize Across Organizations)
Source: Mary & Tom Poppendieck, http://www.poppendieck.com/

16
Lean Traceability
• Flow
– Fine-grained tasks, TDD, feedback-loops
• Minimizing Intermediate Artifacts
• Colocating Both People & Artifacts (locality)
• Coarse Granularity & Modularity/Factoring
• Transparent, Frictionless Automation

17
Waterfall Lifecycle
Breadth-First Delivery
Phase-based Development
End-of-phase Handoffs
Iterative Lifecycle
Depth-First Delivery
Feature-Set-based Development
Full-lifecycle Collaboration
Feature
Set
Feature
Set
Feature
Set
Requirements
Design
Models,
Diagrams
CodeModules,
Classes
Build
Libraries,
Objects
TestBinaries,
Executables
Time
Design
Code
Build
Test
Requirements

18
“Lean” Documentation & Traceability
• Minimize Traceability and Eliminate Redundancy by using Fewer
Artifacts and Separation of Concerns
• Track features/use-cases and classes/modules (instead of their
individual requirements/routines)
– Increases encapsulation + modularity of code and reqt’s
– Reduces number of items to track (by an order of magnitude!)
• Fewer items, means fewer items to track/trace
– Detailed requirements/use-cases may serve double-duty as
acceptance test-cases
– Hi-level requirements/features may be simple feature/change
requests and/or release notes (automatically generated)
– Some end-user documents may even be used as use-cases or
functional requirements documentation

19
Thank You!
Mahalo
XiexieYumboticSalamat
Arigato

Trustworthy Transparency and Lean Traceability

More Related Content

What's hot

Viewers also liked

Similar to Trustworthy Transparency and Lean Traceability

Recently uploaded

Trustworthy Transparency and Lean Traceability