Parnas & Clements' (1986) observations on the practicalities of design conclude that the design process is not equivalent to the SDLC or rational engineering method. They address this contradiction between formal process and practical process by suggesting that the formal process be 'faked'. Allow the practical process to proceed as it inevitably must, as a chaotic flux of learning and refinement, but avoid burdening it by documenting each and every change in minute detail. Instead revise the minimal documentation set if needed or better still produce it at the end with the end-product so that both are in synch. That is, the product drives the documentation rather than the other way around.
Crucially Parnas & Clements recommend that if a design document is used it must remain open to revision as the problems and solutions described in it become better understood, refined, and clearer.
If we think of design work as a kind of learning process then I think their pragmatic solution to managerial formalism can be understood by considering Dreyfus & Dreyfus's (2000) theory of learning. Dreyfus & Dreyfus consider the ways that virtuosity and expertise are expressed by the skilled practitioner, not as an extensive manifold of logico-deducto formalisms, but through insightful performance in a situation. They claim that the graduation of knowledge and competence can be roughly systematised from novice to expert, the process of expert accomplishment does not (and can not) proceed along the same lines. The process of design must therefore be iterative, incremental, producing usable parts that can be tested and give feedback so that the design can evolve towards what is ultimately wanted (not necessarily the same as what might be stated at the outset of the project).
References
Dreyfus, H. L., Dreyfus, S. E. & Anthanasiou, T. (2000) Mind Over Machine: The Power of Human Intuition and Expertise in the Era of the Computer, Free Press.
Parnas, D. L. & Clements, P. C. (1986) A rational design process: How and why to fake it. IEEE Transactions on Software Engineering, 12, 251 - 257.
