© 2006 ibm corporation software engineering in the real world team based software development paul...
TRANSCRIPT
© 2006 IBM Corporation
Software Engineering in the Real World
Team Based Software Development
Paul GibsonDevelopment Operations Manager
IBM Software Group Development Laboratory at Hursley
IBM Software Group
Team based Software Development – Jan 2006 © 2006 IBM Corporation2
Objectives
Understand some of the issues of real world software development projects.
Identify practical responses to these issues.
IBM Software Group
Team based Software Development – Jan 2006 © 2006 IBM Corporation3
Software Project Types
Market Product / Solutions (Approx 1/3) Multi-Customer Multiple Supported Versions Conflicting Requirements
Bespoke Solution (Approx 2/3) Single Customer Requirements negotiable
Personal Requirements understood
Tea
m S
ize
IBM Software Group
Team based Software Development – Jan 2006 © 2006 IBM Corporation4
Software Development Environment
The Dream All the time you need Clear and Stable Requirements A clear foundation on which to build Waterfall or Iterative Development Process All the people you need
Real Life Market & Customer Time Pressure Changing Requirements Dependencies being developed in parallel Overlapping Development Phases Limited Resources & Conflicting Needs
IBM Software Group
Team based Software Development – Jan 2006 © 2006 IBM Corporation5
You start programming – I’ll find out what they want!
IBM Software Group
Team based Software Development – Jan 2006 © 2006 IBM Corporation6
As Team Size Grows above 15 to 20
Problems arise Control Communication
Responses Process & Ownership Organisation & Team Structures Architecture Change Control Code Base Control Progress Tracking
IBM Software Group
Team based Software Development – Jan 2006 © 2006 IBM Corporation7
Control & Communication IssuesDecision Making
Who has the Authority?
Who understands the implications and cost?
Who has to implement?
Who is accountable?
Multiple Teams with Multiple Goals Different Functions (Planning, Design, Develop, Test, Service)
Different Locations & Countries
Different Companies (Co-operation & Competition)
Access to Key Information & Changes to Schedules
Requirements & Specifications
Architecture & Design
Interfaces
Project & Dependencies Status
IBM Software Group
Team based Software Development – Jan 2006 © 2006 IBM Corporation8
Need to Agree….
Organisation Style
Ownership
Aligned Goals
Team Responsibilities
Project Management Process
Communication Processes & Frequency
Education & Skills
HR Policies
Team Building Actions
IBM Software Group
Team based Software Development – Jan 2006 © 2006 IBM Corporation9
Process vs Ownership
Objective
defined process
measurable progress
traceability to specs
documented work
repeatable work
organization focused
compliance praised
High Ceremony
Cognitive
problem-solving
meaningful results
relevance to mission
peer communication
effective work
people focused
technical insight praised
Low Ceremony
Bureaucracy vs Chaos
From James Bach : www.satisfice.com
IBM Software Group
Team based Software Development – Jan 2006 © 2006 IBM Corporation10
Organisation & Teams
As team size grows optimal structure changes
Project > Functional > Matrix > Large Project
Direct Line Management for Ownership
Functional Organisation for Efficiency
Multi-Disciplinary Teams for Decisions
Considerations
Minimise hand offsOrganise for Leaders
IBM Software Group
Team based Software Development – Jan 2006 © 2006 IBM Corporation11
Architecture
As team & project size grows optimal architecture changes
Small, Simple, Uncontrolled Comprehensive, Complex, Controlled
Modularity and Encapsulation become vital
Rigorous Control of all Interfaces
Architecture Board
Considerations
Effective Communication is essential
IBM Software Group
Team based Software Development – Jan 2006 © 2006 IBM Corporation12
Change Control Must have Short Cycle Time ( Iterative )
Control Specification and Product Growth
Database Control of Architecture & Design
All deliverable function raised as Design Change Requests
Further changes tightly controlled
Two Sources of Potential Change
1. Request for Additional Function
2. Implementation or testing uncovers design error
3. (Developer’s “Good Ideas”)
IBM Software Group
Team based Software Development – Jan 2006 © 2006 IBM Corporation13
Change Control Process Formal Request for Change
Review by Project Team & Design Team for
Cost of AnalysisIf cost of analysis is acceptable then
Cost of ImplementationRisk ( Mitigated or Added )UrgencyStrategic ValidityReturn or ValueCustomer Impact
Request formally Committed, Rejected or Deferred
Decision clearly communicated to all
IBM Software Group
Team based Software Development – Jan 2006 © 2006 IBM Corporation14
Codebase Control Challenges
Large project may have 30,000 components
Individual changes potentially effect many components
Single codebase may support multiple releases and multiple platforms in the market
Enable Maximum Reuse
Components can have multiple owners
Multiple Concurrent Development and Service Streams
Delivered by Library Control System / Configuration Management
IBM Software Group
Team based Software Development – Jan 2006 © 2006 IBM Corporation15
Library System Requirements
Base
Feature 1
Feature 2
Feature 3
Fixes required to all streams
Multiple Concurrent Feature and Platform Development
Merge Features with
the Base
Features have PreReqs
IBM Software Group
Team based Software Development – Jan 2006 © 2006 IBM Corporation16
Library System Requirements
Release 1
Release 2
Release 3
Release 4
Fixes Required by Customers
X End of Life
Multiple Concurrent Release Support
Fixes must be merged back to earlier or later releases if code
is not common
IBM Software Group
Team based Software Development – Jan 2006 © 2006 IBM Corporation17
Codebase ControlEnforced by Library Management
All necessary code changes formally tracked and linked to causes / problems
Late & development initiated changes tightly controlled
Multiple Ownership Effectively Managed
Sources of Potential Change
New Requirement Market, Customer, Executive, Development, Test
New Understanding from Iterative Implementation
Defect Discovered Inspections or Analysis detect error Testing detects error In this feature/component, dependent feature/component/product
Field Problem This release or later release
IBM Software Group
Team based Software Development – Jan 2006 © 2006 IBM Corporation18
Codebase Control increases with time
Less restrictive in changes during early code development(Trust everyone)
Rigorously review of all requests for change in later stages (Trust no-one)
Rigorous review for
Potential Customer ImpactRisk of failureRisk of further injectionWorkarounds
Decide what to fix & what to FIN (Fix in Next)
IBM Software Group
Team based Software Development – Jan 2006 © 2006 IBM Corporation19
Progress Tracking Owned by Project Leader
Formal Commitment Tracking
Estimation is critical - based on track records
Include all functional areas
Business, Marketing, Development, Test, Production, Service
Monthly risk assessments
Earned Value Tracking
Rolled up to project level
Communicated, Published, Shared
Metrics & Process Improvement
IBM Software Group
Team based Software Development – Jan 2006 © 2006 IBM Corporation20
SummaryTeam Based Development Issues Identified
Control
Communications
Strategies for dealing with the Issues
Process & Ownership
Organisation & Team Structures
Effective Architectures
Change Control
Code Base Control
Progress Tracking
© 2006 IBM Corporation
Any Questions?
IBM Software Group
Team based Software Development – Jan 2006 © 2006 IBM Corporation22
References
www.satisfice.com
James Bach – Thought provoking views on S/W Development
www.american.edu/academic.depts/ksb/mogit/carmel.html
Erran Carmel - Research on Global Software Teams
www.swebok.org
IEEE Software Engineering Body of Knowledge
www.sei.cmu.edu
Software Engineering Institute
www.methods-tools.com
Software Methods & Tools
www.research.ibm.com/softeng/odc/odc.htm
Orthogonal Defect Classification
www.bcs.org.uk/index.html
The BCS
www.martinfowler.com/articles/newMethodology.html#N400062
Agile Methodologies
www.extremeprogramming.org/
Extreme Programming