There's More Than One Way To Do It
There are lots of good ways to develop software
And many more bad ones
A software development process is a tool like any other
Pick the right tool for your problem domain
Extreme Programming (XP)
Continuous customer involvement
Pair programming
Test, then code
Continuous refactoring
Many short iterations
Little or no long-range planning
Use when:
Major risk is rapidly changing requirements
Team has internalized good working practices
Team is small enough that knowledge can spread by word of mouth
Team members will be around long enough that lack of documentation won't be a problem
ICONIX
Lots of up-front design
Implies longer development iterations
And more forward planning/scheduling
Detailed use cases to analyze user requirements
Derive domain model from use cases
Objects that represent the problem in users' terms
Then develop:
Classes
Usually a superset of the domain model
Includes "extra" classes to handle implementation details
Sequence diagrams showing interactions between classes
Coding is then a (relatively) straightforward translation of documentation into code
Use when:
Low risk of requirements changing
Customer needs to make long-term plans
Team is too large, or project too long-lived, for word of mouth to work
Software is too complex for incremental local optimization to succeed
Cleanroom
Apply hardware design and construction methods to software
A "clean room" is a dust-free chamber in a chip fabrication plant
Mathematical specification of object states at each point in execution
Pre- and post-conditions
Loop invariants
Usually results in many lines of documentation (and proof) per line of code
Detailed code reviews
Developers often spend more time reading each other's code than writing new code
More effective at finding bugs than developers testing their own code
If people have enough self-discipline to do it properly
Use when:
Lives depend on the software
There's no way to patch the software after release
Wrist watches, sensors in automobiles, etc.
System is highly concurrent
Human beings aren't good at thinking about a dozen things at once
How Third Bit Does It
Most teams don't follow any particular process exactly
Here's how one experienced, productive team spends their time
Personnel:
Nine developers
One developer support (installers, build, etc.)
Four QA
One product support
One documentation
One system administrator
One product manager
One overall manager
One secretary/HR/office admin
Starting point:
Version 3.2 of GRACE shipped last week
Version 3.3 has to ship in approximately eight months
So where do we start?
FIXME: diagram of software lifecycle from old intro.ppt
Analysis & Estimation
Product manager gathers requirements from customers
Customers usually say "We want feature X"
Product manager turns that into "We want the product to be able to do Y"
Developers analyze requests
How can the capability be implemented?
Often involves researching new technologies
What are the risks and unknowns?
How long will it take?
Product manager collects estimates
Total time is 6000 programmer-days
But we only have 1600 programmer-days
So product manager has to prioritize
Product manager is not allowed to shave developers' time estimates
This is one of the two most common mistakes in the software industry
The other is not doing enough testing early on
Customers (and your marketing department) will complain
But it's better to live up to small promises than break big ones
End result of A&E process is a schedule that everyone believes in
Yes, it's guesswork
But it's better than nothing
And estimates improve with practice
Design
Developers then finish designs
Often overlaps with analysis
After all, it's impossible to estimate how long it will take to build something if you don't know how you're going to build it
Purpose is to convince people (including themselves) that they can actually build things the way they intend to
Very easy to believe incompatible things when it's all in your head
The act of writing it down (explaining it) forces brings these issues out into the open
Also helps you remember later why you're doing something a particular way
Level of detail varies widely
The better developers understand the product and the technologies it uses, the less risk there is of a lightweight design leading to nasty surprises
The greater the cost of delivering the wrong thing, the more detailed the design should be
But it doesn't help to do a detailed design that customers can't understand
Up-front design is a tool for managing risk
The later you change or fix something, the more expensive it is
But the more time you invest up front, the longer it is until you discover that you need to make changes
Implementation and Maintenance
Write the code
And the unit tests!
These are the developers' responsibility
Often refactor old code while adding new stuff
Your skills (and coding style) improve over time
The problem changes over time
A good solution to last year's requirements may not be a good solution to this year's
Update the design as you go along
If you don't update the design, then:
The next person who has to work with the code will have a harder time
You'll have to start from further behind the next time you need to modify this section
Maintenance usually starts before the product goes out the door
Fix bugs left over from the previous cycle while adding features in this one
Start fixing bugs in new features as QA discovers them
Last quarter of a project cycle is usually nothing but bug fixing
How does this scale up to a large team?
Large end-user application (e.g. multi-site messaging systems)
Personnel:
100-120 developers in 12-15 teams
15 developer support (installers, build, etc.)
15 QA in 2 teams
10 product support
10 documentation
10-15 low-level development managers
3-4 higher-level managers
4 product managers
One overall manager
5-8 admin support: secretary/HR/office admin
Starting point:
Version 1.0 of CallPilot shipped over the last 2 months
Version 2.0 has to ship in approximately 18 months
So where do we start?
Obvious parallels in overall process to small team:
Product managers collect features required/requested by customers
Analysis and Estimation by developers
Implementation and Maintenance
Testing, fixing, etc.
Differences in process - less clean start; more complicated management:
Feature "churn" can take weeks, if not months:
At least two levels of analysis and estimation (one very rough: "wet-finger", others more detailed)
At least two, often more prioritization attempts until the feature set is defined
Development team includes 4-5 UI specialists
They write very detailed feature specifications
Feature specs reviewed with selected customers and by lead designers
Implementation Process and Organization:
In a large system, system architecture defines components - teams/team leaders responsible for a given component (e.g. Device Drivers, File System, Database, GUI or other end-user apps, etc.): "Component Primes"
At least one senior designer together with the UI specialist is responsible for any given major feature: "Feature Primes"
Feature Primes negotiate requirements with Component Primes:
To implement feature A we need the following changes in components X and Y
Component Primes, in turn, discuss their changes with other Component Primes: to change X, we'll need to change W and Z (which makes it harder to do feature B - but that's why it's so interesting to work on large systems...)
This process may uncover obstacles and costs that require re-thinking of the feature set more than once: "churn"
Has to be managed carefully: costly and demoralizing
A host of other issues and interrelations among features adds to the complexity (not restricted to large systems):
"We must be able to sell and price feature C separately"
"We don't need to spend the money making feature D available in BBC English Male Voice"
"A major customer is threatening to switch if E is not available by March"
Once the feature set is (relatively) firm:
Feature test writing and end-user documentation can start
Component Primes produce design documents,
Coding and unit testing begins.
Managing the interdependencies of a large project can still be a nightmare
F has to be ready before G, G before H, but F needs H, or a reasonable prototype
Quality Assurance
QA starts before the product is available
As soon as feature specifications are firm, QA can:
Start making up lists of tests to run
Start writing utility programs
And of course, there's always the previous version to keep testing...
QA's usual role is to find bugs in the finished product
Yes, developers should do this as they're coding
But in practice, they are usually too focused on particular features to find wider issues
Plus, developers tend not to be good at testing
Subconsciously don't want to find problems
But "Trying to improve the quality of software by doing more testing is like trying to lose weight by weighing yourself more often." (McConnell)
In a mature organization, QA helps identify why bugs are occurring
So that developers stop making that kind of mistake
Other Activities
Documentation also starts before product is available
Describe new GUI screens based on mock-ups drawn for A&E
Write new on-line help
Starting work on installers the same day you start on new features
Overnight "build and smoke" test
Check code out of version control at 1:00 a.m.
Compile on all platforms
Report any differences in compiler output
Run unit tests
Everyone has a status report in their mailbox at 5:00 a.m.
Issue Tracking
How does a team keep track of:
What features have been asked for?
What bugs have been found?
Who's supposed to be working on what?
Use an issue-tracking system
Sometimes called a "bug tracker"
But can be used for much more
The heart of the tracker is a database that records:
What the issue is (feature request, bug fix, etc.)
Who created it
Its priority
Show-stopper
Cosmetic
Somewhere in between
Its state
Newly-filed
Confirmed or rejected (e.g. a duplicate or unreproducible)
In progress
Ready for test
Closed
Who is responsible for it right now
When it has to be completed
Associated material
Version control change IDs
Test input files, output logs, etc.
Issue tracking system is a communications medium
Developers talking to QA and support
"This is ready for test"
QA and support talking back to developers
"It's still broken"
Everyone talking to managers
"This is what I did this week"
"This is where we are"
For patches and up-issues: the set of issue-reports fixed in the up-issue defines the release
FIXME: diagram of state changes in issue tracking system
$Id: lifecycle.html,v 1.1.1.1 2004/01/04 05:02:31 reid Exp $