Shell Method™ Software Engineering Process Repository
The basic model An abstract representation that illustrates the components or relationships of a specified application or module. we envision when we think about documentation is after we prepare it and deliver it to the client, the client carefully reads it and provides written feedback, treating it as a high priority item. This model is flawed.
The reality is our precious document winds up in a sea of other documents on the client's desk, each competing with the others for the client's attention. The client, being human, prefers to stay in his or her comfort zone, and naturally focuses on documents that address familiar subjects. Developers are paid to do database development because it is not a familiar subject to the client. Hence, our documents are outside the client's comfort zone, and quite naturally wind up being ignored as much as possible.
The old technique of printing up an original, stapling a distribution list to the front of it, and sending it around for people to add their comments is guaranteed to kill your project. Even if we do the circulation electronically, there's just too much lag time in each iteration, and the project becomes stale.
Clue: A stale project has a really good chance of failing. Project participants lose interest, they recruit others to take their place, and the new people have different ideas. The project is then in a death spiral of changing and conflicting requirements. The most successful projects keep their original participants, and provide enough "action" to keep them engaged. This is one of the key advantages provided by the Shell Method.
The Shell Method makes use of eight "secrets" to enable development teams to rapidly produce high-quality, well-documented software:
Formal project documentation
Requirements elicitation presentations
End-user community integration
Prototypes and online meetings
These are further described in the remaining pages in this folder.