Before "Object Oriented Programming" (all the rage of the software industry for the last decade), there was "Structured Programming", the industry's rage for the previous decade. Both of these fashions are needlessly convoluted instantiations of a few more general and powerful processes, which have application well beyond just programming. Indeed, those fashions have given rise to a whole host of "description" languages in an attempt to facilitate their use. But it has only exacerbated the problem of unnecessary complexity. Formal methods from academia generally have not helped the software development effort either. Engineers are not trained in the methods; very little tool support exists; and proofs are both longer and more difficult to construct than the software itself.
Beneath all the industry hype and academic esoterics, there are 3 core processes alluded to earlier, that provide an adequate basis for superior software development:
Abstraction and specificity complement each other. Abstraction is the process of giving a name to a complex "something", where that name is much simpler than the description of the "something" being named. Specificity is the complementary/opposite process, describing in much greater detail "something" that is an abstraction.
Composition and decomposition also complement each other. Composition is the process of combining 2 or more "somethings" into a whole. Decomposition is the complementary/opposite process, separating a "something" into its constituent components.
The use of lucid domain-specific natural language, is another way to say, using natural language in a clear, concise, consistent manner, supplemented with well defined technical terminology from whatever application or problem domains apply. Natural language includes the use of audio/visual aids (drawings, pictures, prototypes, demos, etc); though the easily violated requirement of lucidity remains.
The HY-SPECS TM development process is rather straightforward and simple: in lucid domain-specific natural language, begin with the most general/abstract description of the project concept, and successively refine (ie, iteratively specify and decompose) that description until executable software and customer documentation is produced, using hypertext to link composed abstractions down to their specific constituent components, and to link such components up to their context and purpose/motive.
The result of this development process is a rough tree structure of descriptions (ie, specifications), rooted at the project concept, growing downward through the requirements and design, with executable software and customer documentation as the tree structure's leaves. Every 1 or 2 levels of greater specificity and decomposition correspond to the classic Waterfall Model phases of concept, requirements, design, and implementation. See Appendix I for an illustrative sketch. The specifications of each level are verified internally first, and then verified and accepted externally by the customer, before great effort is expended at the next deeper level. Each level is a consistent and complete semantic expansion of the level above it, with about half an order of magnitude greater detail.
Generally speaking, this downward progression occurs in a breadth-first manner. However, narrow portions may be taken to a much deeper level before other portions, if the need arises. This is often called "rapid prototyping" or "multi-phased development", and is best done for components requiring more customer input, or for components that are otherwise riskier and need early stabilization.
In order for the HY-SPECS TM development process to be effective, specified "somethings" should be named, and decomposition should be into disjoint constituent components. Naming is essential for ease of reference and lucid description. Disjoint decomposition is much more difficult to perform; but the more disjoint the requirements and design components are, the more loosely coupled and highly cohesive the source code components will be. Disjointness leads to orthogonality, which enables the modification of one component without unwanted side-effects on other components.
One may wonder how the tail end classic Waterfall Model phases of testing and maintenance fit into the HY-SPECS TM development process. A distinct phase for integration is also common among industry. The testing phase is subsumed by the verification that occurs at each level of the development process. This is an important difference because defects will be found sooner, with immense savings in time, effort, and cost. Activities that traditionally occur during the maintenance phase, defect fixes and enhancements, are treated no differently than if they occurred against a release prior to "final delivery" (an oxymoron for any supported software). Defect reports and enhancement requests are entered, and the appropriate modifications are percolated through the affected development process levels, culminating in another release. The integration phase is handled much like the testing phase. Interface and other integration issues are specified and verified at each level of the development process, beginning at either the project concept or requirements levels; there should be no such unpleasant surprises at the end of the project.
The HY-SPECS TM development process adheres to SEI CMM Level 2 by institutionalizing particular meta processes:
The HY-SPECS TM development process is artifact-centric, meaning that nearly all development related processes and SEI CMM related meta processes operate on or produce tangible artifacts, for example, a human readable document such as the project's Software Design Overview Spec. Whereas the voluminous 479 page CMU/SEI-93-TR-025 technical report may make a statement like "The SQA group reviews the software engineering activities to verify compliance", we would state that the artifacts produced by those activities are verified for compliance. Notions of activities, procedures, and processes that have no associated artifact are virtually impossible to control or manage, hence the HY-SPECS TM development process' heavy emphasis on tangible artifacts.
Copyright © 1999 UnixYes, Inc., All Rights Reserved.
HY-SPECS, the checkmark logo, and We don't do windows!
are trademarks of UnixYes, Inc.
All other trademarks are held by their respective owners.