Your New Teammates
The team with whom you now work produces semi-automated inventory systems. A typical
system includes RFID scanners in the warehouse, web-based reporting of inventory
levels, automated email alerts when an inventory item is getting too low, automatic
ordering, etc. The top selling point to customers is usually the slick custom reports
that the system can produce.
Since this group has delivered over two dozen of these projects in the last few years, the programmers have a bunch of code that they like to reuse. The two requirements gatherers (Sue and Bob) are pretty good at talking with customers, including the clue-less managers, the blue-collar guys on the dock, and the old secretaries who really know how things work. (Word to the wise, never play poker or pool with either Sue or Bob.) The team has four other members: Tim, Zack, John, and The Other Bob. They do all the coding and testing.
The Current Development Process
At the bottom of this page is the usual development schedule.
For the first two weeks, the two requirements
people find out what the customer wants. About the second week, the four programmers
know enough to start building a design (also usually a modified version of a past
project). By the forth week, coding can start. Actually, most of the coding work
is recoding/tailoring existing code. Everyone knows to stay out of
the four geeks' area during that time. Just throw a pizza over the cubicle wall as
you leave for the day - they do their best work around midnight.
Once the coders emerge from their cave, and after they shower, all six team members start playing with the system to pound out obvious errors. Sue and Bob have an ability to think like end-users. The four programmers enjoy testing because they get the chance the tweak each others code - i.e. point out everyone else's errors, thus proving they are the best programmer.
The Team "Leader"
Note, there is a seventh member of the team - Dave. Dave is technically
considered the team's leader, but he is often found on the golf course with a VP
or a manager from the customer's company. But, Dave does love for the group to
make weekly status presentations to him.
Dave uses a unique process metric for quality assurance. If the customer had a lot of specialized requests, then the programmers' pizza box wall is probably quite tall and quality is suspect. But, if there are no boxes and the four geeks are discussing their marathon game sessions, then Dave is happy that the project is going well.
Customer Relations
Starting in week nine of the project, the software goes to the customer's site.
Sue and Bob start training the customers.
Tim, the only programmer who owns a tie, also goes to the customer's site. Tim tells the customer he is there to do on-site system performance testing and data verification. Actually, he is there to watch for problems. He hangs out in the IT office and when errors pop up, he gets on the cell phone to the other three programmers who hack out a patch. Tim installs the patch and waits for the next error to pop up.
After a few weeks of this, the system runs enough to be useful. Also after a few weeks of use, the customer accepts that the system will crash once a week. It really helps that Dave always tells the customer's managers to expect this level of operability. Of course, Dave doesn't use the word "operability", and his comments come as subtle comments made while on the golf course.
Hopefully, the system will not decide to order 1,000,000 cardboard boxes instead of 10,000.00 boxes, which seems to happen surprisingly frequently. Compatibility of the software with the customers' hardware and operating systems is another frequent problem. It always amazes Tim how many different web browsers that people use.
Here is where you come in...
Since Dave is now under huge pressure to improve his group, he is willing
to take your advice. After all, you are an outsider, so that makes you an expert.
A friend of yours who knows all the personalities, recommends not trying to shoot for CMM Level 5 right from the start. It is agreed that a formal test plan would make a nice first step that would be acceptable to all involved.
Your assignment is to produce an outline of an appropriate test plan. You meet with Dave tomorrow morning at 9:00am.
Group Roster:
The Big Boss - your VP, rarely seen except in photos
Dave - your manager, nice tan
Sue - customer relations, would do well in the Sales Dept
Bob - customer relations, good ole boy in a suit
Tim - programmer / on-site development rep
Zach - programmer, fairly new young guy
John - programmer, I think he programmed on the EDVAC, wears shorts even in winter
The Other Bob - programmer, plays four different musical instruments
| Usual Development Schedule: | ||||||||||||||
| 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | |
| Sys Req Gathering | ||||||||||||||
| System Design | ||||||||||||||
| Software Design | ||||||||||||||
| Coding and Component Integration | ||||||||||||||
| Testing | ||||||||||||||
| User Guide Creation | ||||||||||||||
| Installation and Training | ||||||||||||||
| Production Testing |