trustworthy transparency and lean traceability
TRANSCRIPT
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]
COMPSAC 2006Chicago, IL, September 17-21, 2OO6
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
COMPSAC 2006Chicago, IL, September 17-21, 2OO6
30th Annual International Computer Software & Applications Conference
Trustworthy Transparency & Lean Traceability
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
COMPSAC 2006Chicago, IL, September 17-21, 2OO6
30th Annual International Computer Software & Applications Conference
Trustworthy Transparency & Lean Traceability
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
COMPSAC 2006Chicago, IL, September 17-21, 2OO6
30th Annual International Computer Software & Applications Conference
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)
Trustworthy Transparency & Lean Traceability
Brad Appleton
COMPSAC 2006Chicago, IL, September 17-21, 2OO6
30th Annual International Computer Software & Applications Conference
Trustworthy Transparency & Lean Traceability
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
COMPSAC 2006Chicago, IL, September 17-21, 2OO6
30th Annual International Computer Software & Applications Conference
Trustworthy Transparency & Lean Traceability
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
COMPSAC 2006Chicago, IL, September 17-21, 2OO6
30th Annual International Computer Software & Applications Conference
Trustworthy Transparency & Lean Traceability
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
COMPSAC 2006Chicago, IL, September 17-21, 2OO6
30th Annual International Computer Software & Applications Conference
Trustworthy Transparency & Lean Traceability
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
COMPSAC 2006Chicago, IL, September 17-21, 2OO6
30th Annual International Computer Software & Applications Conference
Trustworthy Transparency & Lean Traceability
10
4 Rings of Stakeholder Visibility-- Roger Sessions
Brad Appleton
COMPSAC 2006Chicago, IL, September 17-21, 2OO6
30th Annual International Computer Software & Applications Conference
Trustworthy Transparency & Lean Traceability
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
COMPSAC 2006Chicago, IL, September 17-21, 2OO6
30th Annual International Computer Software & Applications Conference
Trustworthy Transparency & Lean Traceability
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
COMPSAC 2006Chicago, IL, September 17-21, 2OO6
30th Annual International Computer Software & Applications Conference
Trustworthy Transparency & Lean Traceability
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
COMPSAC 2006Chicago, IL, September 17-21, 2OO6
30th Annual International Computer Software & Applications Conference
Trustworthy Transparency & Lean Traceability
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
COMPSAC 2006Chicago, IL, September 17-21, 2OO6
30th Annual International Computer Software & Applications Conference
Trustworthy Transparency & Lean Traceability
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
COMPSAC 2006Chicago, IL, September 17-21, 2OO6
30th Annual International Computer Software & Applications Conference
Trustworthy Transparency & Lean Traceability
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
COMPSAC 2006Chicago, IL, September 17-21, 2OO6
30th Annual International Computer Software & Applications Conference
Trustworthy Transparency & Lean Traceability
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
COMPSAC 2006Chicago, IL, September 17-21, 2OO6
30th Annual International Computer Software & Applications Conference
Trustworthy Transparency & Lean Traceability
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
COMPSAC 2006Chicago, IL, September 17-21, 2OO6
30th Annual International Computer Software & Applications Conference
19
Thank You!
Mahalo
Xie xieYum boticSalamatKhawn khun
Spacibo
Arigato
Juspajaraña
DankeTrustworthy Transparency & Lean
TraceabilityBrad Appleton