|Okon, Walt, Computer Engineering - Three Approaches To Software
Development, www.waltokon.com, 16 September 2002
|Evolutionary Approach To Software Development
We have agreed that the Evolutionary approach may be used for any product for which there is a significant expectation of requirements growth in the foreseeable future. It has been much more difficult to agree on an example of when the Evolutionary approach should be used. Your task is to develop criteria for when to use the evolutionary approach. You should consider the dimensions of management, process, and product in defining the criteria. Give examples to make your criteria easy to understand and to apply.
By Walt Okon
There are two Software System Engineering Lifecycle Models. They are the Evolutionary lifecycle model and the Interactive lifecycle model for the development of software intensive systems.  Dr. Andrew Sage describes the existence of three general life cycle models for software development taken form MIL-STD-SDD planned for issue as MIL-STD 498. 
1. The Grand Design lifecycle in which there is a single pass through of each phase of development as in the Walter Fall Model.
2. The Incremental lifestyle model is one where there is an iterative process or a sequence of builds, with each build bringing in more functionality of the original design based on the original user requirement. These user requirements were then defined into the original System Requirement Specification (SRS). Once, the user validated the SRS they are not changed and the design is developed and fielded in incremental releases.  Once established the SRS is not subject to change or modification.
3. The Evolutionary lifecycle model is one where the software results from a sequence of iterative builds as in the incremental lifecycle. However, it is recognized the user’s requirements are not fully defined and will change during the lifecycle. Not all of the user’s requirements are captured during the original requirement identification and Systems Requirement Specification (SRS) development process. The evolutionary lifecycle model allows for the user to identify and refine the requirements and add new functionality during design, development, . With each build there will be requirement analysis, requirement identification, and SRS change for each builds and release. 
The Evolutionary life cycle capability leads to a proactive management style with enabling methods. The Evolutionary ("Evo") Project Management Method has proved to be a very successful software project management method.  It so successful that it was used in the IBM "Cleanroom" method and is a DoD and IEEE standard. It is used by both HP and Microsoft in their development efforts.  The Evolutionary life method is a powerful proven method for getting control of projects through feedback and adjustment to the design and development process. It is a method of dealing with the pragmatic realities of users requirement change, rather than by struggling to identify all the user requirements under the pressure of a delivery schedule.
Today, technology provides many challenges to providing highly dependable software design and development. Advances in hardware and in software have forced us into the Electronic Business/Electronic Commerce world which demands an accelerated process in everything we do. Organizations today find themselves is the “Progress or Perish” mode. Survival depends on getting or delivering fast software release cycles and growth
rate of services. The technology driven “Progress or Perish” business environment has caused us to violate one of the traditional dependable computing principles of “minimizing change” of the last decade. The demand for fast release cycles causes the software and the development of software to be different.
Traditional design and testing paradigms, focused on the pre-deployment phases of a service, are not sufficient to cope with runtime problems caused by immature software, unexpected workload, network changes, system integration, and operator errors. Even the most careful design will not correctly predict and handle all incarnations of hardware,
software, operator and environmental faults.  User requirements, network infrastructure, and system integration of applications all are in a constant state of change.
The demands of the Electronic Business/Electronic Commerce world have pushed software development and software engineering into a “Progress or Perish” state.
The Evolutionary lifecycle model accommodates incremental development using experience from earlier increments to help define requirements for subsequent
increments. If we think of just development which results in operations/maintenance, you can see that in the Evolutionary lifecycle model the process can be repeated and repeated. (Figure 1).
(Figure 1) The Evolutionary lifecycle model.
In the generic view, increments of the software development process are developed sequential, rather than in parallel, and with in each incremental development cycle, there is a normal progression through requirement analysis, design, code, test and implement, followed by progression through another requirement analysis, design, code, test and implementation followed by operations and maintenance. Now, just looking at the operations and maintenance stage for an increment, there will be feedback from users which will cause a reiteration of some steps of development for that increment. This will in turn result in a re-lease of that increment; a new version release.
Despite the fact that Dr. McKenzie states that development is not in parallel , experience with large software development system applications  shows each finished release is incorporated in requirements for the next development cycle. Within the processes of the processes (requirement analysis, design, code, test and implementation), development is on going in many different stages. For example, the DOD Electronic Business Exchange ( DEBX ), Design Review  shows that there are teams of personnel (82 people in all) all working continuously using the “continuous approach” to do software development in their area; requirement analysis, design, code, test and implementation.
From the customers' point of view, the system provides service. This service, which is really a continuum software development processes, will continue to "evolve" as increments are delivered over time. From the developers' point of view, those requirements that are clear at the beginning of the project will dictate the initial increment, and the requirements for each development cycle there after will be
clarified through the experience of developing prior increments. This is evidenced by the technology described in the DoD EB Architecture Version 4.0 which constitutes a paradigm shift in the overall approach to managing the development of EB for the department of Defense and the Government.  Whereas past architecture approaches have been top-down efforts in the past within a particular organization or functional area, this new EB Architecture effort seeks to facilitate communication across functional communities and across organizations. Therefore, by its very nature becomes a service using the “continuous approach”.
EVOLUTIONARY MODEL BENEFITS
The benefits of the evolutionary lifecycle model include:
a. early delivery of portions of the system even though some of the requirements are not yet decided;
b. system becomes operations faster and benefits of the system are realized from early releases while later releases are being developed. 
c. use of early releases as tools for requirements elicitation
d. continuing and professional efforts of an established requirement analysis team
e. continuing and careful documentation
f. continuing functional and integration testing with constant feedback
g. continuing user feed back through user interface conferences and configuration control boards
h. constant In Progress Reviews (IPRs) by the development team to the design team
i. over-site and coordination by the architecture team
j. system measurement in all areas for design through analysis
k. funding management and control to maintain senior management decision control
l. ability to restructure existing delayed projects and get them delivered earlier than otherwise possible 
EVOLUTIONARY MODEL LIMITATIONS
Limitations of the evolutionary lifecycle model include:
a. difficulty estimating costs and schedule at the start of the project when scope.
b. difficulty in establishing a software design and development team
c. difficulty in defining the project overall elapsed time
d. difficulty in cost measurement when there is realization of continuing development.
e. time apparently gained on the front end of a project because of early releases may be lost later because of the need for rework resulting from evolving requirements;
f. additional time must also be planned for integration and regression testing as increments are developed and added to the system;
g. care must be taken to ensure that the evolving system architecture is both efficient and maintainable so that the completed system doesn't resemble a patchwork of afterthought add-ons.  However, this limitation which is still prevalent in most software development organizations has been mitigated by recent work demonstrated on the DoD EB Architecture Version 4.0 which constitutes a paradigm shift and provides a “living architecture”. 
h. traditional design and testing paradigms, focused on the pre-deployment phases of a service, are not sufficient to cope with runtime problems caused by immature software, unexpected workload, and operator errors.
CRITERIA FOR WHEN TO USE THE EVOLUTIONARY APPROACH
Senior software system engineers and software development directors have to make the decision on which software development lifecycle approach will be taken for a development effort. Dr. Andrew Sage has clearly describes the three general life cycle models for software development as the Grand Design, Incremental, and Evolutionary lifecycle models.  As explained above, the software developers today have the advantage of technology tools. They also, have the disadvantage of the technology driven society. The software decision maker (software development director) will chose to use the Evolutionary lifecycle model when the following criteria or conditions exist and he has to answer “yes” to these questions:
a. Is the software development project complex?
b. Will there of necessity be multiple iterative development cycles? 
c. Will there have to be deployment of interim software deliverables?
d. Is the system too large or complex for a one time “out the door” build?
e. Will the user have additional requirements that must be satisfied?
f. Is there and immediate need for some functionality?
g. Will the need for this system be long term?
h. Will there be pending technology advances which can increase/improve future functionally?
i. Is the user community geographically dispersed and requirement collection time consuming and complex?
j. Will the system require an extensive network infrastructure (Internet +) to reach world wide?
k. Is the development funding constrained?
l. Will a large and highly skilled software requirement, design, development, testing, deployment, and architecture teams be necessary?
If the software decision maker (software development director) answers “yes” to the criteria questions or “yes” to most of those questions, the Evolutionary approach should be used. Evolution in software development becomes a continuous services and it can be view as or similar to the spiral model of software development . The feedback loop from system behavior and requirements to development are continuous. Today’s technology and “rate of change” constant and fast. Adaptation to changing workloads and integration clearly emphasis the advantage of the Evolutionary approach.
. Sage, Andrew P., Systems Management For Information Technology and Software Engineering, John Wily & Sons, New York, 1995, Page 110.
 U. S. department of defense. Military Standard Software Development and Documentation, DoD STD-SSD, (Draft), 1992.
. Sage, Andrew P., Systems Management For Information Technology and Software Engineering, John Wily & Sons, New York, 1995, Page 116.
 International Institute for Software Testing, Software Project Management: An Evolutionary Approach, URL http://www.softdim.com/iist/courses/evolutionaryprojman.htm
 Chen, Mike Y. , Kiciman, Emre, and Brewer, Eric, An Online Evolutionary Approach to Developing Internet Services, University of California at Berkeley, Computer Science Division. URL http://22.214.171.124/search?q=cache:j86SA4RZu7QC:www.cs.berkeley.edu/~mikechen/papers/online-evolution-draft.pdf+%22Evolutionary+approach+%22&hl=en&ie=UTF-8
 EVOLUTIONARY LIFECYCLE, URL http://metr.cua.edu/faculty/mckenzie/mis327/Evolutionary.html
 EC Engineering, DoD Electronic Business Exchange (DEBX), URL http://eblibrary.jecpo.anvi.com/ec/debx/ URL http://eblibrary.jecpo.anvi.com/ec_infra_appl/debx/debx_v2_2draft/sdd.pdf
 Okon, Walter J., DoD eBusiness Architecture, version 4.0, URL
 Okon, Walter J., DoD eBusiness Architecture, version 4.0, URL
 B. Boehm. A Spiral Model of Software Development and Enhancement. IEEE Computer, 21(2):6172, May 1988
PHASES OF THE SPIRAL LIFE CYCLE
2. The Spiral life cycle model is well known for its usefulness in developing products for which “surprises” are likely to occur. An example might be a research project, in which the surprise would be an unexpected property of the system when its parts are integrated into a whole. We call such surprises emergent properties of the design, and we have identified the prediction, identification, management, and control of emergent properties as the principal goal of systems engineering. Your task is to examine the phases of the spiral life cycle and identify and describe what the systems engineer should be doing at each of these phases to address emergent properties of the design. You may use any published spiral model, such as Boehm’s model as given in class. For each task that you identify for the systems engineer, you should say how the task will facilitate the prediction, identification, management, and control of emergent properties. You should describe each task and give an example of how the task is performed. Your examples may come from other engineering courses, from your place of business, or from any referenced source.
PHASES OF THE SPIRAL LIFE CYCLE
By Walt Okon
Software developers in software engineering organizations have to choose a method of software development. In order to speak and communicate with each other they must speak the same language. They speak the language of design, development and architecture. A common infrastructure in their language is invariably the water-fall development process. It defines a clear set of processes that can easily be described. The credit for the introduction of this system engineering based lifecycle is generally attributed to Royce  who defined the terms as the Waterfall-model. If this model was just accepted as basically defined it would produces artificially frozen set of requirements documents for use in the next step in the development life cycle. If this process continued with its constrained definitions it would restrict users and handicap developers by resisting inevitable and desirable changes in requirements.
The spiral life-cycle model addresses a more real approach. The spiral life cycle model adds to the waterfall model by providing an incremental development process, in which developers repeatedly evaluate changing project requirements to manage dynamic development capability and funding issues. Such a lifecycle acknowledges the need to develop software architectures that are stable, yet adaptable, in the presence of changing requirements. The great strength of the Spiral model is the capability to develop increments, or prototypes, with each full turn of the Spiral. 
PHASES OF THE SPIRAL LIFE CYCLE
The spiral model represents several iterations of the waterfall model with a possible new approach or capability to software development at each iteration. Dr. Andrew sage has stated that this is often called the Incremental lifecycle.  Dr. Sage describes the phases of the Spiral lifecycle.
1. The Spiral lifecycle first phase is the development of a model, or a prototype of the user system requirements.
2. The Spiral Lifecycle second phase is the determination of the software requirements and the associated technical specifications.
3. The Spiral lifecycle third phase is the preliminary, conceptual, or architecture design.
4. The Spiral lifecycle fourth phase is sometimes called the Grand Design.
Dr, Sage goes on to describe very completely the phase or a collection of phases comprising a cycle or a round of the spiral lifecycle. In particular there are steps that can be taken in each round of the spiral.
This is where the objectives or user requirements are considered on terms of performance, functionality, and ability to accommodate change.  Requirements and Specifications.
This is where there is a determination of and the evaluation of the alternatives in relation to the objectives (Requirements) and constraints (risks). Requirements and Specifications.
This is where the original hypothesis is tested. Preliminary Concept Design Architectures
This is where the plans for the next cycle of development are identified. Final Development and Deployment.
Dr. Sage in his book, Systems Management For Information Technology and Software Engineering, describes the activity matrix for a spiral lifecycle (Page 123). This is an excellent abbreviated definition of each activity in software development.
The Spiral lifecycle because of its iterative process is very helpful to the understanding of feedback, reuse, evolution development, requirement analysis and continuous process improvement. It treats the development and usage alike and seeks to provide a dynamic software development and usage environment, at the same time, for changing information needs in changing organizations.  The whole model of the Spiral lifecycle allows for such emergent properties of to be facilitated, managed and decisions made in regard to them. Emergent properties are parts of a system with some properties that are not directly dependant on the properties of its parts; these are called emergent properties.
The spiral lifecycle model is a model of change and the processes within the Spiral model by the nature of the model favor change and continuous improvement; or development. This Spiral lifecycle model is very responsive to business change as we are seeing in electronic business and electronic commerce. This is where the development and the architecture is a “living/growing” development. All this is benefit to the users and developers. The software engineer benefits because there is a process and a language that can be used to ensure the right questions are addressed by the right people at the right time. The User benefits because better software is developed with better functionality at a reduced cost.
A good example of emergent properties is the software development of the “Electronic Portal Access Services (EPASS)” . The defined user requirement task was to develop and provide “a Single Sign On, Electronic Business access services to include an automated registration process for vendor and Government personnel that facilitates the conduct of DoD Electronic Business”  During the initial requirements analysis, only Single Sign-On and user registration were identified as user requirements. However, the DoD EC Engineering division which held the lead for the software development and deployment if approved, made a decision to use a spiral development lifecycle model for development and system integration. This decisions was based on the fact that Spiral model lent itself to the evolutionary approach and would provide the opportunity for development and program adjustment.
Emergent properties discovered early in the Formulation phase where the objectives or user requirements were considered in terms of performance, functionality, and ability to integrate. The task was to produce a Functional Requirement Document using customer elicitation and requirement analysis. While doing customer elicitation and writing the Requirement identification, it became evident that Smart Security, and network security (DMZ) were emergent properties or derived requirements. In phase 2 of Formulation, (Software Requirement and Specification) the requirement analysis engineers along with the development engineers identified software to be used. Through the study and configuration of the emergent properties (derived requirements) of Single point for PKI and its maintenance User Profiles was identified. In phase 3 of Formulation (Identify Preliminary Conceptual Product Design Architecture), the development team, the design team, the integration team, and the engineering management team met to come up with a preliminary high level design concept and architecture. Again the emergent properties or derived requirements, became evident. A PKI Authentication and Authorization application would have to be developed to work with the DoD PKI Authentication certificate system. This emergent property of the design was another additional development effort. In phase 4 of Formulation (Identify Preliminary Final development and Deployment Phases), the requirement engineer, the integration team, and the engineering management team realized that the National Security Agency (NSA) would have to be consulted. The program manager and the Chief Engineer met with NAS officials an agreed that a security concept would have to be addressed and approved. The EC Engineering Division took the lead along with NAS security engineers to design the security concept for the DoD. All the derived emergent properties were a direct result of going through the Spiral Life Cycle process.
It is critical to note here that the Chief, EC Engineering, the integration engineer and the program manager are all responsible for REQUIREMENTS TRACEABILITY.  Each new emergent requirement must be documents to provide traceability from each requirement in the specification to the system requirements it addresses. A System/Subsystem Specification (SSS) which specifies the requirements for the system/subsystem that have not been developed for the EPASS Prototype system (or for any system). Therefore, traceability of the software requirements for emergent properties identified in this SRS to the system/subsystem requirements stated in the SSS cannot be accomplished at this time. But, they are to be traced upon discovery.
Emergent properties discovered in the Analysis step. Analysis step is where there is a determination of and the evaluation of the alternatives in relation to the objectives (Requirements) and constraints (risks). Requirements and Specifications. In phase 1 of Analysis (Analysis of risk and develop User Requirements and Specification prototype), the development team along with the systems administration team built and installed the prototype. At the same time the requirement analysis technical write was putting together the SRS. The discovery made during this phase was the fact that the different applications would not integrate/configure together. This cause the development of another Government Off the Shelf (GOTS) code for the integration of the registration software with the new Fire Walls being installed through the network. In phase 2 of Analysis (Analysis of risk and develop Software Requirements and Specification prototype), the development team along with the systems administration team discovered that they needed assistance form the EC Engineering team, NSA engineers and the Defense Information Systems Agency (DISA) Information Assurance (IA) designers. This effort resulted in the prototyping, design, development, and fielding the new DoD DMZ network security concept. In phase 3 of Analysis (Analysis of risk and develop Preliminary Conceptual Product Design prototype), the development team along with the EC Engineering design team, and the system integration team completes the Conceptual Product Design or what we call the high level design. Here we discovered a new and more efficient interface to user applications. The new interface was described, configured, and tested. It was then documented and included into the Traceability documents. In phase 4 of Analysis (Analysis of risk and develop Final Development and deployment prototype of Operations), the development team, the EC Engineering design team, and the system integration team completes the final development and deployment documents. Development is on going over live networks. Geographical separated sites are established. Plan builds occur every week. System integration meeting occur each Friday for the next build. This is the rapid development phase. We are now on schedule with an operational prototype with all systems running and five major applications being serviced.
Emergent properties discovered in the Interpretation -1 and 2 steps. The software engineer teams continue their processes based on the Spiral Lifecycle model. During these steps and phases, the feedback and analysis loops and systems are firmly established. Sample and measurement become part of the processes and the emergent properties are that these emergent properties are to become a part of the system when before they were not directly dependant on or part of the system or the original system.
Software developers must have a method of software development in order to speak and communicate so they can design and develop. Common infrastructure in their language is invariably the Water-Fall development process. However, the spiral life-cycle model adds a real approach by providing an incremental development process, in which developers repeatedly evaluate changing project requirements to manage dynamic development capability and funding issues while achieving early production and efficiency. The Spiral lifecycle allows emergent properties of to be facilitated, managed and decisions made to integrate them into the core development. Using these principles results in quality software engineering with effect and effective products to the customer.
. Sage, Andrew P., Systems Management For Information Technology and Software Engineering, John Wily & Sons, New York, 1995, Page 111.
 Bashar Nuseibeh, Weaving the requirements and architecture together, The Open University, URL: http://www.doc.ic.ac.uk/~ban/pubs/computer2001.pdf
 Barry Boehm "A Spiral Model of Software Development and Enhancement"
IEEE Computer, vol.21, #5, May 1988, pp 61-72.
. Sage, Andrew P., Systems Management For Information Technology and Software Engineering, John Wily & Sons, New York, 1995, Page 119.
. Sage, Andrew P., Systems Management For Information Technology and Software Engineering, John Wily & Sons, New York, 1995, Page 121.
 Patel, Nandish V., Developing Tailorable Information Systems through Deferred System's Design, Department of Information Systems and Computing, Brunel University
Uxbridge, UB8 3PH, United Kingdom, URL: http://ais99.sba.uwm.edu/Papers/002.pdf
 JECPO Electronic Portal Access Services (EPASS)
 Department of Defense, Electronic Portal Access Services (EPASS) Prototype, Software Requirements Specification (SRS), DI-IPSC-81433, Version 1.1 (Final), March 8, 2001 URL: http://eblibrary.jecpo.anvi.com/ec_infra_appl/eportal/index.html
  Department of Defense, Electronic Portal Access Services (EPASS) Prototype, Software Requirements Specification (SRS), DI-IPSC-81433, Version 1.1 (Final), March 8, 2001 URL: http://eblibrary.jecpo.anvi.com/ec_infra_appl/eportal/index.html , Page 34.
 Patterson, F.G., Lifecycles for System Acquisition, School of Information and Technology, George mason University, USA, Page 17.
 S Bennett, S McRobb and R Farmer, Software Analysis and Design, Object Oriented Systems Analysis and Design, Mc Graw Hill,1999, URL:
CAPABILITY MATURITY MODEL INTEGRATED
THE CONTINUOUS APPROACH
3. The Capability Maturity Model (Integrated), or CMMI is currently being phased into software organizations in every kind of enterprise. There are two fundamental approaches. There is the staged approach, which bears a strong resemblance to the original software CMM, and there is the continuous approach. Your task is to consider the continuous approach, to discuss the merits and deficiencies of the continuous approach as compared to a staged approach, and to characterize projects that would benefit from the continuous approach. What kinds of projects should choose the continuous approach instead of the staged approach? Do your conclusions hold true for other areas besides software, such as systems engineering? Why would anyone ever use the continuous approach?
CAPABILITY MATURITY MODEL INTEGRATED
THE CONTINUOUS APPROACH
By Walt Okon
The Capability Maturity Model (CMM) was created to improve software development. The Capability Maturity Model (CMM) for software was developed by Carnegie Mellon, Software Engineering Institute (SEI) specifically to provide software organizations with guidance on processes for developing and maintaining software. (5) Its purpose was to provide or set in place a culture change to organizations that were in the software development business. The hope is to set into the culture the processes that could measure and ensure that software development was excellent.
Much of the work on CMM was sponsored by the Department of Defense.  The DoD became concerned about their ability to produce good software. The objective was to create a process where by the DoD would have a center of Excellence for software development. DoD questioned its process maturity and the extent that it as an organization could define its processes, actively control these processes, and provide systematic human and computer-based support for them. 
Specifically, what was the DoD problem? The DoD was in need of a Command and Control System to integrate all the military services actions in a in a war during attacks. The answer to this was to be the World Wide Military Command and Control System (WWMCCS). It began in the late 1970's as an effort to provide the president, the Defense secretary, the Joint Chiefs of Staff and other military authorities with information to help them make wartime decisions.  The system was too slow and limited, it could not get the integrated information to the right person at the right time in order to made a command decision during attack. DoD launched the software development of WWMCCS Information System (WIS) upgrade project . The Air Force was the developer has suffered several setbacks since being selected in 1982 to manage WIS. In July 1987, the WIS program office announced the system would be delayed about a year due to funding cuts and system development problems.  The real problem was that two Lieutenant Colonels from the United States Air Force (Lt Col. Walt Okon and Lt Col. Randy Lee) stationed at the new United Stated Transportation Command stationed at Scott Air Force Base discovered and proved that the Data Base source code developed by Air Force in the WIS was faulty and would never work.
The General Accounting Office reported that program officials had not adequately defined system requirements and security measures.  Subsequent funding problems delayed the project by another 12 months to15 months. The press reported that Air Force officials who requested anonymity said OSD officials recently set up a task force to propose alternative methods to upgrade WWMCCS in light of WIS program difficulties. Lt Col. Okon traveled to Washington DC and met with software engineers at the Defense Communications Agency (DCA) and showed they the source code and what real development needed to be done. DCA software engineers agreed that they could do the job and be successful and a fraction of the cost. Mr. Glenwood Stevener, Director of DCA's Joint Data System Support Center, said the Air Force's WWMCCS Information System (WIS) program was a victim of a vicious circle of schedule slippage. 
Officials in the Office of the Secretary of Defense (OSD) transferred the responsibility for software development of the Worldwide Military Command and Control System (WWMCCS) from the Air Force to the Defense Communications Agency. Mr. Stevener said that DCA would take more of an ``evolutionary'' approach (Continuous Process Improvement) to the upgrade. He said the Air Force has been attempting to develop and field a turnkey system to fulfill a broad range of WWMCCS requirements. The DCA plan would focus on a fielding a partial system at first and incrementally adding capabilities to it.  Mr. Stevener selected Colonel Okon and moved him DCA in Arlington, Virginia to work directly for him as a Special Assistant to the Director and the Total Quality Management Director for the DCA's Joint Data System Support Center. 
CONTINOUS PROCESS IMPROVEMENT
Mr. Glenwood Stevener, Director of DCA's Joint Data System Support Center was now responsible for software development of the Nation’s largest Information Technology (IT) software development. He established a software development improvement project for the software developers in Joint Data System Support Center. First wanted to know how good his one thousand developers were in comparison to industry software development. Mr. Stevener commissioned a Process Action Team (PAT). The PAT was lead by Mr. Michael Roach, lead software engineer; Mr. Robert Welsh, resource manager; and Lt Co. Walt Okon, Total Quality Management Director. They lead a team of engineers who visited industry for bench marking, worked with Carnegie Mellon, Software Engineering Institute (SEI) for guidance on processes for development and accomplished an internal as is process model.
Maturity levels were studied.  Putnam and Myers’ book on “Measures For Excellence, reliable software on time, within budget” was used as one of the reference tools. Mr. Roach noted that the software process improvement program developed by Watts s. Humphrey of the Software Engineering Institute had five levels of achievement.  The first step was to define the current state of the Joint Data System Support Center’s ability to do software development. It is important to note that while the PAT was ongoing software development never stopped. The software development engineering teams were busy with requirement definition, design, development, plan builds, code builds, testing, system integration testing, and deployment. The goal was software development excellence. The general direction was a new release of WWMCCS every six months in accordance with the direction to implement Continuous Process Improvement.
Mr. Roach was determined to identify and describe activities as part of the existing process. Dr. Twyla Courtot would reason that this is important so you do not “throw the good out with the bad”.  Mike Roach wanted to demonstrate the organization was using sound engineering practices which were in conformance with quality management practices. He was not really thinking that process improvement begins with an understanding of the existing system.  What he had was Humphrey’s five levels of achievement or maturity levels. Humphrey defined them as 1. Initial – schedules and cost are not under predictable control, 2. Repeatable- commitment, cost, schedules, and changes are under control, 3. Defined – a basic set of process activities is defined, making it possible to measure them, 4 Managed – the organization initiates comprehensive process measurement and analysis, 5 Optimizing – the organization has the basis to improve the process and to measure the extent of improvement.  At the end the first three month, Mike Roach and his team reported our Joint Data System Support Center software development processes were being identified. The organization maturity level was level 1 and level 2. Mr. Robert Welsh, resource manager reported cost were not under control but a cost accounting process was designed and recommended. Lt Col. Walt Okon reported on the development of a Total Quality Management Implementation Program. He designed analysis and measurement processes. The first customer requirement conference was held by the requirement and analysis team.
The merit of the continuous approach is that depending on the organization and the personnel skill along with the processes in place there is the ability to do parallel actions, activities, and process development at the different stages at the same time. What the continuous approach brings to the table is the ability to achieve success in the core development product while making process improvement. This becomes a culture and a “way of life”. In the staged approach, the organization strive for a level goal and the personnel to not expand their horizons to the upper level even though some can in their individual processes.
CAPABILITY MATURITY MODEL® INTEGRATION (CMMI®)
The Capability Maturity Model® Integration (CMMI®) is derived from the multiple Capability Maturity Models for the purpose of creating something good and providing an increase in clarity and understanding.  It is really a maturing of the CMM of the 80s into a CMMI of the 90s which provides the guidance for improving an organization's processes and ability to manage the development, acquisition, and maintenance of products and services. CMM® IntegrationSM places proven practices into a structure that helps your organization assess its organizational maturity and process area capability, establish priorities for improvement, and guide the implementation of these improvements.  Where the Capability Maturity Models (CMMs) contain the essential elements of effective processes for one or more bodies of knowledge that DCA’s Joint Data System Support Center employed in the 80s, now the Defense Information Systems Agency is in the process of embracing the current Capability Maturity Model® Integration (CMMI®). Where the CMM elements are based on the concepts developed by Crosby, Deming, Juran, and Humphrey,  the CMMI Product Suite springs from a framework that generates multiple integrated models, courses, and an appraisal method.
The CMMI model has a continuous representation, which focuses on measuring process improvement using capability levels. The continuous approach is the ability to make continuous improvement in each process. This is to say that there are many processes in each of the maturity levels. Within each of those processes, there are processes. Process improvement can be made continuously for each process. Therefore, the organization and the individual achieves successes which strengthen the organization and the individual in a continuous way. Therefore, there is a validation of the capability levels apply to process-improvement achievement within individual process areas such as Configuration Management or Verification.  Dr. Twyla Courtot, Center for Systems Management, October 2002, states it very simply; “What level in the organization is process improvement performed?” The answer is “ALL”.  She correctly states there is increasing process maturity at all levels in the continuous approach as compared to a staged approach.
WWMCCS PROJECT BENEFITED FROM THE CONTINUOUS APPROACH
Did the World Wide Military Command and Control System (WWMCCS) upgrade benefit for the continuous approach? Did Mr. Glenwood Stevener’s, Director of DCA's Joint Data System Support Center implementation of Continuous process Improvement work? Was the Department of Defense (DoD) and the Military Services successful? It is acknowledged that the implementation of the continuous approach is more complex and less focused. It is acknowledged that the continuous approach requires more leadership, commitment, training, resources, and a culture change. But, the benefit was a culture change and the belief of the organization that their improvement was continuous and professional. Did the WWMCCS of the Vietnam area become vastly improved under Total Quality Management of W. Edwards Deming and his “Continual Improvement”?  WWMCCS did not control the joint force attacks of the services in Vietnam. But, the proof of the effectiveness of the Continuous Approach was realized during Desert Storm. WWMCCS was evolved through continuous improvement and its scheduled version releases. It evolved into the Global Command and Control System (GCCS). It was successful in the command and control of the joint Service attacks in Desert Storm. There were fewer American deaths in Desert Storm than in any other War. The “Continuous Approach” work well for a very complex system and a very complex process of software development.
Our conclusions does hold true for other many areas besides software, such as systems engineering, with requirement definition, design, development, plan builds, code builds, testing, system integration testing, and deployment. It was also implemented for acquisition, cost accounting and resource management. For a major system in a complex organization, the continuous approach is the only logical approach using the staged approach as a goal and measurement while continuing on with Continuous Process Improvement.
. Carnegie Mellon, Software Engineering Institute, http://www.sei.cmu.edu/cmmi/general/
Carnegie Mellon University, URL: http://www.sei.cmu.edu/cmmi/general/general.html
Last Modified: 15 October 2002
. Carnegie Mellon, Software Engineering Institute, Carnegie Mellon University, URL: http://www.sei.cmu.edu/publications/documents/02.reports/02tr028.html
Last Modified: 14 October 2002
. Carnegie Mellon, Software Engineering Institute, Carnegie Mellon University, Capability Maturity Model® Integration (CMMISM), Version 1.1, CMMISM for Software Engineering (CMMI-SW, V1.1), Continuous Representation, CMU/SEI-2002-TR-028
ESC-TR-2002-028, by:CMMI Product Team, August 2002
 Capability Maturity Model® Integration (CMMISM) Overview, by; Dr. Twyla Courtot, Center for Systems Management, October 2002, page 5.
. Sage, Andrew P., Systems Management For Information Technology and Software Engineering, John Wily & Sons, New York, 1995, Page 467.q
 JDSSC. Joint Data Systems Support Center Air Force as Special Assistant to the Director and the Total Quality Management Director for the Defense Systems Support Organization.
 Kotonya, Gerald and Sommerville, Ian, Requirements Engineering, Wily & Sons, New York, 1998, Page 45
 “Continuing problems with WWMCCS command-and-control network”, By: Jon Jacky firstname.lastname@example.org, 17 Feb 1989, excerpts are from GOVERNMENT COMPUTER NEWS Feb. 6, 1989 p.1:, URL: http://catless.ncl.ac.uk/Risks/8.28.html
 Okon, Walter J. URL: http://waltokon.com/WaltBio.html
Note; DCA's Joint Data System Support Center was renamed to the Defense Systems Support Organization.
 Putnam, Lawrence H. and Myers, Ware, Measures For Excellence, reliable software on time, within budget, Yourdon press, Prentice Hall Building, New Jersey 1992, Page 177.
 Capability Maturity Model® Integration (CMMISM) Overview, by; Dr. Twyla Courtot, Center for Systems Management, October 2002, page 15.
 Capability Maturity Model® Integration (CMMISM) Overview, by; Dr. Twyla Courtot, Center for Systems Management, October 2002, page 48.
 Deming, W. Edwards, Out of the Crisis, Massachusetts Institute of Technology, Cambridge, Massachusetts, 1986, page 466.