The emperor is not wearing any clothes. The SEI CMM Level 3 defined approach to systems development does not and cannot work. Research between ADM, Vmark, Borland, and DuPont Advanced Research Facility has proven that systems development is an empirical process that requires controls. The controls ensure adequate risk of management and adequate response to the unknown and unexpected.
A war is raging as some of the most respected names in the industry try to apply the rigid, stifling development of the past to OO. They are confronted in the marketplace and on the Internet by the successes and commentary of those who are building the best possible software using SCRUM like approaches.
More successful organizations use a revolutionary systems development process: Scrum. Scrum contains the essence of development at these and other successful organizations. SCRUM (the word comes from the game of rugby) enables OO through advanced iterative, incremental development within a controlled environment. It allows organizations to build the best possible OO systems possible.
OO development requires a different development process. SCRUM is not a step-by-step cookbook approach. SCRUM requires active, thoughtful development and management. Assessing, adjusting, thinking - these are the characteristics of a successful SCRUM.
Many new development approaches have failed. IS managers are so desperate for a "silver bullet" that the salesmen joke that IS management has to turn over every three years to support the "silver bullet" software industry. CASE is a great example.
Failed approaches have become emperors without any clothes: everyone knows that they don't work, but everyone is embarrassed to say so. One failure builds on another.
The Capability Maturity Model from the Software Engineering Institute represents the current fad. Not that the concept of improving processes is wrong. It's just that the systems development process is not defined past level two. That doesn't stop gaggles of consultants from selling "self-improvement" programs to get organizations to level 3. Too bad that it doesn't work. The whole philosophical basis of level 3 defined processes is wrong.
As organizations have succeeded with empirical, controlled approaches to systems development, the chasm between them and SEI proponents has become apparent. Now the two sides yodel at each other from either side, both in the press and the Internet.
Systems development is the act of creating a logical construct that is implemented as logic and data on computers. The logical construct consists of inputs, processes, and outputs, both macro (whole construct) and micro (intermediate steps within whole construct). The whole is known as an implemented system.
Many artifacts are created while building the system. Artifacts may be used to guide thinking, check completeness, and create an audit trail. The artifacts consist of documents, models, programs, test cases, and other deliverables created prior to creating the implemented system. When available, a meta model defines the semantic content of model artifacts. Notation describes the graphing and documentation conventions that are used to build the models.
The approach used to develop a system is known as a method. A method describes the activities involved in defining, building, and implementing a system; a method is a framework. Since a method is a logical process for constructing systems (process), it is known as a meta process (a process for modeling processes).
A method has micro and macro components. The macro components define the overall flow and time-sequenced framework for performing work. The micro components include general design rules, patterns and rules of thumb. General design rules state properties to achieve or to avoid in the design or general approaches to take while building a system. Patterns are solutions that can be applied to a type of development activity; they are solutions waiting for problems that occur during an activity in a method. Rules of thumb consist of a general body of hints and tips.
Applying concepts from industrial process control to the field of systems development, methods can be categorized as either "theoretical" (fully defined) or "empirical" (black box). Correctly categorizing systems development methods is critical. The appropriate structure of a method for building a particular type of system depends on whether the method is theoretical or empirical.
Models of theoretical processes are derived from first principles, using material and energy balances and fundamental laws to determine the model. For a systems development method to be categorized as theoretical, it must conform to this definition. Models of empirical processes are derived categorizing observed inputs and outputs, and defining controls that cause them to occur within prescribed bounds. Empirical process modeling involves constructing a process model strictly from experimentally obtained input/output data, with no recourse to any laws concerning the fundamental nature and properties of the system. No a priori knowledge about the process is necessary (although it can be helpful); a system is treated like a black box. Primary characteristics of both theoretical and empirical modeling are detailed in Table 1.
We assert that the systems development process is empirical:
Applicable first principles are not present;
The process is only beginning to be understood;
The process is complex;
The process is changing;
You can't expect a method to tell you everything to do. Writing software is a creative process, like painting or writing or architecture. A method supplies a framework that tells how to go about it and identifies the places where creativity is needed. But you still have to supply the creativity.
Categorizing the systems development methods as empirical is critical to the effective management of the systems development process. If systems development methods are categorized as empirical, measurements and controls are required because it is understood that the inner workings of the method are so loosely defined that they cannot be counted on to operate predictably.
In the past, methods have been provided and applied as though they were theoretical. As a consequence, measurements were not relied upon and controls dependent upon the measurements weren't used. Many of the problems in developing systems have occurred because of this incorrect categorization. When a black box process is treated as a fully defined process, unpredictable results occur. Also, the controls are not in place to measure and respond to the unpredictability.