Trustworthy Transparency and Lean Traceability

COMPSAC 2006Chicago, IL, September 17-21, 2OO6

30th Annual International Computer Software & Applications ConferenceCOMPSAC 2006

Chicago, IL, September 17-21, 2OO630th Annual International Computer Software & Applications

Conference

Trustworthy Transparency& Lean Traceability

20 September 2006

Brad AppletonSoftware CM/ALM Solution Architect

Arlington Heights, [email protected]


30th Annual International Computer Software & Applications Conference

Trustworthy Transparency & Lean Traceability

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

TraceabilityBrad Appleton




3

7 “Wastes” of Software Development1. 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

Brad Appleton




4

6 Facets of Traceability1. Change Impact/Dependency Analysis2. Product Conformance3. Process Compliance4. 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

Brad Appleton



5

4+2 Views of SCM/ALM ArchitectureOrganization Management

Teaming & CollaborationProducers & ConsumersMetrics/Reports/Audits

PhysicalConceptual

ContentContext

decision binding-time &change/creation time

diversity& scaleProject

Project/Program Managers, QA/V&VStatus AccountingRequest/Defect ManagementChange Planning/Tracking

CR

CR

CR

EnvironmentIT Engineering/Support

Workspaces/Repositories Application Integration

Computing Infrastructure

EvolutionIntegrators/Release MgrsVersioning/BaseliningBranching & MergingParallel Development

Product

Architects/Engineers/BuildersProduct/Artifact Structure

Build/Release Engineeringchange/creation-time& decision binding-time

scale &diversity

Cop

yrig

ht ©

199

7-20

06 b

y B

rad

App

leto

n

ProcessProcess-users/engineers

Process WorkflowProcedures/TrainingPractices/Patterns

(Who)

(What)

(When) (Where)

(Why)

(How)


Brad Appleton




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

Brad Appleton




7

5 Orders of Ignorance (Armour)0th Order Ignorance (0OI) – Lack of Ignorance: I know

something1st Order Ignorance (1OI) – Lack of Knowledge: I don’t

know something2nd Order Ignorance (2OI) – Lack of Awareness: I don’t

know that I don’t know something3rd 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

Brad Appleton




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

Brad Appleton




9

4 Fundamental Values of Agility1. Individuals and interactions over processes and

tools2. Working software over comprehensive

documentation3. Customer collaboration over contract negotiation4. Responding to change over following a planThere 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

Brad Appleton




10

4 Rings of Stakeholder Visibility-- Roger Sessions

Brad Appleton




11

3 Driving Forces for Traceability1. 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.

Brad Appleton




12

2 Overarching Objectives for Traceability1. 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.

Brad Appleton




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

Brad Appleton




14

Achieving AgilityResponding 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!

Brad Appleton




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/

Brad Appleton




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

Brad Appleton




17

Waterfall LifecycleBreadth-First Delivery

Phase-based DevelopmentEnd-of-phase Handoffs

Iterative LifecycleDepth-First Delivery

Feature-Set-based DevelopmentFull-lifecycle Collaboration

FeatureSet

FeatureSet

FeatureSet

Requirements

DesignModels,Diagrams

CodeModules,Classes

BuildLibraries,Objects

TestBinaries,Executables

Time

Design

Code

Build

Test

Requirements

Brad Appleton




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

Brad Appleton



19

Thank You!

Mahalo

Xie xieYum boticSalamatKhawn khun

Spacibo

Arigato

Juspajaraña

DankeTrustworthy Transparency & Lean

TraceabilityBrad Appleton

Trustworthy Transparency and Lean Traceability

Software

Transcript of Trustworthy Transparency and Lean Traceability