bivio Software, Inc. - Software That Works.
 home  |  projects  |  pro bono  |  library  |  bOP  |  our team  |  about us  |  contact

CSCI 3308 XP Intro: Classical Software Methodologies   Back to first slide   Previous slide   Next slide  
of 24

  • Customers provide complete requirements [rock]

  • Analysts translate requirements into specifications

  • Coders implement according to "the spec"

  • Reviews and audits ensure the spec is met

  • Testing is performed by a third party (avoids congnitive dissonance)

  • Maintenance means modifying as little as possible (old code is good code)


Notes:

[rock] The "get me the rock" story describes a manager-subordinate relationship where the manager doesn't have all the answers. The manager asks for a rock and the subordinate gets one, but without a complete specification, the subordinate gets the wrong rock. The story iterates over various types of rocks with the manager getting more and more upset, because the subordinate cannot read her mind.

The story actually is about a customer relationship. The manager is acting as the customer. She doesn't know what she wants until the subordinate starts building something. Classical software methodologies say that the manager must provide a complete specification up front or her subordinates will be unable to complete the task.

Analysts bridge the gap between programmers (coders) and the customer. The difference between requirements and specifications is semantics. Usually, a requirements doc can be read by the customer and the spec is much more detailed and technical. Essentially, the analyst acts as a translator between customer-speak and programer-speak.

Coders are not supposed to deviate from the spec. A spec is a solid plan of going forward. If you code outside the spec, random things will happen during testing. Your modules won't be compatible with other people's modules.

Reviews and audits are performed by different subgroups to ensure their parts conform to spec, including coding guidelines interface specifications. A review is performed after the coder or analyst is done. Inertia has set in.

Testing is best left to a third party. Coders can't test their own code, because they have a conflict of interest. If they find bugs, they've failed. Cognitive dissonance theory says that a programmer will have natural inclination towards optimism. "My code works. I just need to do a few tests"..

The system is put into production. You change as little as possible. The specification is set in concrete and serves as a bible. System maintenance documentation is complete. User manuals have been written. Any changes require updates to all of this. Change is very expensive.

© 2009 bivio Software, Inc.