Spiral development of C4ISR system performance

This article was published in ISBN 951-25-1499-0, National Defence University Finland 2004

A VARIATION OF SPIRAL DEVELOPMENT AND ACQUISITION METHOD APPLIED TO MILITARY COMMAND, CONTROL AND COMMUNICATIONS SYSTEM PRODUCTION

C3 SYSTEM DEVELOPMENT METHODS

EVOLUTIONARY ACQUISITION AND METHODS OF DEVELOPMENT

Evolutionary acquisition is an acquisition strategy that defines, develops, produces or acquires, and fields an initial hardware of software increment (or block) of operational capability. It is based on technologies demonstrated in relevant environments, time-phased requirements, and demonstrated manufacturing or software deployment capabilities.

These capabilities can be provided in a shorter period of time, followed by subsequent increments of capability over time that accommodate improved technology and allow for full and adaptable systems over time. Each increment will meet a useful capability specified by the user. The first increment may represent only 60 percent to 80 percent of the desired final capability.

There are two basic approaches to evolutionary acquisition:

1. the ultimate functionality can be defined at the beginning of the program, with the content of each deployable increment determined by the maturation of key technologies. This is called waterfall development method.
2. the ultimate functionality cannot be defined at the beginning of the program, and each increment of capability is defined by the maturation of the technologies matched with the evolving needs of the user. This is called spiral development method.

WATERFALL APPROACH

Traditionally, in the incremental development, the platform or "end deliverable" is clearly stated in the work description. It might take an integrator a decade or more to deliver a complex fleet of aircraft or a weapons system (as example a space shuttle). Because modern technologies, especially information technologies, change so rapidly, a platform may be outdated before it is ready for service. But after the initial design phase, the contractor cannot easily make major changes. One who wants to re-engineer the platform to meet a new mission or take advantage of a new technology, must start working on the next-generation system.¹

Another approach for waterfall development is modified for renewal or upgrade projects. Pre-planned product improvement (P3I) is a traditional acquisition strategy that provides for adding improved capability to a mature system. P3I has operational system to start with and strictly specified end states to reach at.

SPIRAL APPROACH

“The Spiral Development Model is a risk-driven process model generator for guiding multi- stakeholder concurrent engineering of software intensive systems. Its distinguishing features include a cyclic approach for incrementally growing a system’s degree of definition and implementation, and a set of anchor point milestones for ensuring feasibility of the incremental definitions and implementations”²

The spiral development method is an iterative process for developing a defined set of capabilities within one increment. This process provides the opportunity for interaction between the user, tester, and developer. In this process, the requirements are refined through experimentation and risk management, there is continuous feedback, and the user is provided the best possible capability within the increment. Each increment may include a number of spirals. Spiral development implements evolutionary acquisition.

An increment or block is a useful and supportable operational capability that can be effectively developed, produced or acquired, deployed, and sustained. Each increment of capability will have its own set of thresholds and objectives set by the user. The major spiral model features:

• cyclic concurrent engineering;
• risk driven determination of process and product;
• growing a system via risk-driven experimentation and elaboration; and lowering development cost by early elimination of nonviable alternatives and rework avoidance.

As a result of planning and risk analysis, different projects may choose different processes. That is, the spiral model is actually a risk-driven process model generator, in which different risk patterns can lead to choosing incremental, waterfall, evolutionary prototyping, or other subsets of the process elements in the spiral model diagram. The Spiral Development includes some misconceptions. The most significant misconceptions to avoid are:

• that the spiral is just a sequence of waterfall increments;
• that everything on the project follows a single spiral sequence;
• that every element in the diagram needs to be visited in the order indicated and that there can be no backtracking to revisit previous decisions.³

A Spiral Development consists of a spiral divided into four quadrants. Each quadrant represents a management process, namely:

• Identify;
• Design;
• Construct; and 
• Evaluate.

The method goes through four cycles of these four processes:

1. Proof-of-concept cycle

• It defines the business goals, captures the requirements, develops a conceptual design, constructs a "proof-of-concept", establishes test plans, conducts a risk analysis. Shares results with user.

2. First-build cycle

• It derives system requirements, develops logic design, constructs first build, evaluates results. Shares results with user.

3. Second-build cycle

• It derives subsystem requirements, produces physical design, constructs second build, evaluates results. Shares results with user.

4. Final-build cycle

• It derives unit requirements, produces final design, constructs final build, tests all levels. Seeks user acceptance.

Spiral development has some specific features to be utilised in suitable projects:

• It does not specify a product, allowing instead the contractor and agency to work in partnership to find the best solution.
• Contractors can incorporate new technologies into new weapon platforms and systems, rather than delivering solutions using only those technologies that existed when the systems were initially designed.⁴
• The contractor uses a modular approach, in which features are built independently of one another, so that a problem with one component won't necessarily slow development of others.

DEVELOPMENT AND BUDGETING

The budgeting of today`s C4I systems prefers waterfall development. Specially military budgeting in defence materiel is either:

• Long term planning and budget is fixed some 5 years before the product reaches even the first prototype.
• Short term planning and budget is viable only one year. Development programs have to rival yearly of their funding and some times priority is set in another order.

In one example of space based C4I -system development conducted in U.S.A, the incremental development proved to be more cost effective than spiral development. This was due the long phase of user tests that were not productive enough from the satellite system point of view. Analysis done in this project provided three alternative mistakes in the Budgeting a Spiral Development project:⁵:

1. Use and learn will be ignored, funds will be programmed early.

Real spiral development never materializes.

2. Timing will be delayed.

Spiral development will occur, but too slowly from time – cost perspective

3. Funding structure will change

Current budgeting is favouring a long term waterfall or P3I development projects and short time budgeting demands cycles shorter than 10 months, which sets a difficult timeline to achieve any operational level development.

U.S. Department of Defence started a special program for spiral development SPADE (Spiral Program Acquisition and Development Enabler). SPADE-program is Air Force led and features new tools like:

• Money used for second and third iterations of projects designated as “spiral”
• Money contained in its own Portfolio Of Management (POM). Programs receiving SPADE funds are chosen by Air Force leadership
• Only previously funded programs (programs with their own POM) are eligible for funding.
• Anything funded with SPADE is immediately placed in budget for further funding. (Transition funding is only available to those programs that will be continuing on to a second iteration)
• Total size of SPADE is approximately 1/20 of Air Force procurement budget.

BENCHMARKED PROJECTS

Expeditionary Force Experiment 1998⁶

One of the U.S Air Force programs for developing more efficient C3-systems is Expeditionary Force Experiment 1998 (EFX -98). EFX-98 is the first of several planned annual experiments designed to determine how well the Air Force, using advanced command and control capabilities, could respond with little or no warning and quickly halt an invading force. EFX-98 will be a live-fire, live-fly and simulation experiment that will put advanced command and control systems still under development into the hands of actual warfighters.

The process followed in developing, testing and fielding these EFX initiatives is an excellent example of spiral development. Spiral development is an innovative method to field a system quickly using commercial and government off-the-shelf equipment with maximum user involvement throughout the process. It is the operational feedback during all phases of development that makes this process work. The process takes advantage of rapidly evolving new technology in the commercial world and the establishment of a common operating environment for future command and control systems.

The actual product, the Theatre Battle Management Core System(TBMCS), which is the baseline command and control system for EFX, version 1.0 was not yet fielded, when the program wanted the contractor, Lockheed, to develop an EFX version 0,5 concurrently. The contractor provided program with some initial code, and the EFX-team began the spiral one integration work. The program then brought the version 0,5 system to the Command and Control Training Innovation Center to get the warfighter’s input on how the system performs. They put the operators in front of TBMCS v. 0,5, had them work with it, and sought their feedback. Technical people were included with notebooks and took down more than 40 memorandums. Then the technical crew set about finding a fix for each feedback.

With spiral one a success, the EFX team began preparations for spiral two. The contractor made the next "drop of software code," and module by module, that code was integrated into the overall architecture. Drops of code bring new capabilities for warfighters along with those from previous editions.

Several lessons were learnt from the first EFX, but the Spiral Development proved effective in two ways:

1. The drops of code come much quicker than commercial software releases, since the spiral cycle duration was between 3 to 18 months.
2. One can attempt to design systems and interoperability on paper, but for a successful, warfighting-relevant, interoperable C2 weapon system to be delivered, EFX is teaching, that one must provide an interactive feedback environment with the operators.

U.S. Army Missile launch co-ordination⁷

The Army needed a way to coordinate missile launches, not only among its own field sites but also with the Korean military. Before the system was commissioned in 1998, missile launches were coordinated by phone or fax -- a slow, cumbersome process. The Army wanted a computer-based system that could coordinate attacks. However, the Army did not specify how the software for this, called the Automated Deep Operations Coordination System, should work or what features it should have. Instead, the Army left the task of fulfilling the requirement to General Dynamics, which sent engineers to the field to show prototypes to end users, who critiqued the design. The company made changes to the software based on user input, returned with the results and repeated the process. Only when a design was finalized did it get vetted through the necessary officials. "We shortened the development span from months down to days," Project leader comments.

TRANSFERABLE OPERATIONS CENTER DEMONSTRATION

The Transferable Operational Centre (TOC) demonstration is aiming to present an approach to future processes and tools for Command and Control (C2) and Policy and Planning (P&P) of military operation. The project is developing the survivability of command posts (CP) by dividing Headquarters (HQ) into smaller elements (CP elements), distributing them over a wide area being able to transfer between different access points. While strengthening survivability, the TOC concept is supporting both C2 and P&P processes by enhancing their virtual collaboration, information management and process integrity. The demonstration includes technological, organisational and methodological development.

OPERATIONAL CONSEPT

The TOC project itself is a part of more complex evolution of Command, Control, Communications, Computers and Intelligence (C4I) in The Finnish Armed Forces. TOC concept is based on demands defined in the guidelines of 2001 white paper and further studies of security and defence policy. TOC project focuses on C3 services of a command or a subtheatre level. It will mainly have effects on:

• The processes level
• The Command Post structure level
• The Information Systems level and
• The infrastructure level of a C4I system.

The architecture is divided into three substructures: processes, information systems and platforms, which consists of networks and command posts. In the processes substructure, the TOC project is aiming at update and beef up both command and control and policy and planning methods used at military operational level. In the IT substructure, the TOC project is aiming at information services, which are less command post or stovepipe centric. In the platform substructure, the TOC project is aiming at a command post structure, which can tolerate up to 50% of casualties, while maintaining all C3 processes up and running. The network substructure on the other hand is providing robust and transparent channels for mobile and movable communications and web-services.

The C3 processes developed in the TOC project are divided into the

• command and control method and
• plans and policy method.

The first process is to develop and sustain the idea of operation and produce an operational plan. The second process is to conduct the planned operation and all support elements needed to be synchronized. In order to enhance processes, the project has chose four key factors:

1. virtuality in geographical, organizational and IT-system levels,
2. ability to change processes,
3. competence management and
4. knowledge management.

The project is seeking ways to support both P&P and C2 processes with these key factors keeping the collaboration between staffs being in the highest priority. They are further benchmarked with some modern business best practices and traditional military methods. While automating as much as possible of the processes, the tools must be survivable and robust since manual tools and methods are no longer an option.

TECHNICAL CONCEPT

The command post (CP) structure is formed to enhance survivability. Instead of having a single, slowly transferable headquarters (HQ), the project introduced a squirm of command post elements. Each element consists of five staff officers and two support persons. These elements could house in fixed shelters, containers, vehicles or carry their computers in suitcases. Elements can be deployed together in close quarters or distributed over a wide area network (WAN). Each element is operable within 15 minutes from arrival and due departure. The access is wireless (WLAN), so CP-element housed in a vehicle, the arrival and departure are even quicker.

The survivability is adjusting by itself with variation of shelter, number of elements and movement. On duty a CP-element is parked by the hotspot access point but offduty CP-element can move from one hotspot to another. The HQ is operating in a virtual mode. Services and databases are clustered in network serving whole theatre of battle. An enemy has to invest a lot of resources to eliminate over 50% of the distributed HQ.

Information and communication technology is supporting the network based command post structure with clustered information powerhouses, which provide all necessary information processing, storing and presenting services as well as communication means. The access to those services was provided by IP-access network. The user terminal was designed as lean configuration, self-operated and as transferable as possible. The different services were integrated into the same terminal equipment i.e. telephone, 2-tier client-server applications and information pulling services. Special attention is put to the information security features since all three levels of confidentiality is served: public, restricted and secret.

TOC DEVELOPMENT METHOD

The task for the project was to study all alternatives even the most innovative, in order to enhance survivability and effectivity of the HQ´s at strategic-operational level, the objective was blurred and project was asked to define demand on the way.

The C4I system is constructed of resources (people), processes (methods of staff work) and technology. The alternatives for business development were:

• radical (totally new approach for C4I from scratch to fulfilment),
• life-cycle (renewing from existing ways of doing little by little) or
• incremental (introducing radical changes to real life in small phases).

The spiral development (i.e. Incremental development) was chosen as well because the TOC project was given to operational unit at theatre level (Northern Command). Normally these project were conducted under Defence Staff with Materiel Establishment or other units specified in military system development.

The spiral development of TOC started with a contribution from specialists representing wide variety of businesses. After talks with system providers, research organizations, business consultants and different military developers, the first draft of definitions and objectives was created. This is called thinking big. Then the first spiral was decided to implement and prove first wins. After approval and learning in operational environment, the second spiral was created and so on. This spiral development, implement and testing phases forced all three parts of C4I structure to develop. Staff officers were relearning their way of planning and conducting operations, old EDP-tools were modified to new use and command post service did evolve along the other parts of HQ daily working.

APPLIED SPIRAL DEVELOPMENT METHOD IN TOC PROJECT

FEATURES OF THE SPIRAL METHOD DURING 2001 – 2003

The project plan includes four main parts:

• The Research and Studies supporting actual spiral development project
• The Definition of Demands for architectures and systems, which focuses into the processes, survivability and IT-services
• The gradually developed testbed for Command Post and Information Technology solutions
• A series of exercises and occasions defined to prove and test each spiral phase and produce lessons learnt-documentation

The project did not start to evolve all parts of architecture at the same time, but chose firstly prove some new technology to open thinking and introduce basics for virtual command post. After that the focus have been put on the processes and development of whole business system. 

The initial idea for spiral development of transferable operation centre was to increase survivability by network based command post structure. To support this approach both information services and staff processes demanded enhancements.

First Spiral Cycle – Transferability

The first effort was to show how CP can be transferable while all IT-services remain stable. It included:

• Three containers to improve teamwork and give a platform for ergonomy development
• 15 worksites for staff officers, 5 sites per each container
• One server hotel for client termination
• One VoIP-exchange for computer integrated telephone services.

The implementation phase took three months with one week technical approval tests and then one week operational test. The major lessons learnt were:

• Thin client is possible without pure n-tier applications with client termination
• The support needed for workstation operation can be minimized at users capability level
• Computer telephone integration introduced conference talks in new approach
• Information powerhouse services do able transferable command post containers movement from access point to access point with minimal update time.

Second Spiral Cycle – Distribution

The second cycle was established around bigger command post exercise (CPX), which included over 50 users and a number of command post sites. The aim was to implement and prove further transferability, introduce wider scale of IT services both restricted and secret and introduce portable terminal for staff officers. The implementation took four moths followed by first technical approval, two week reconfiguration and two week CPX. It included first cycle services added with:

• 50 portable user terminals built in suitcases
• 12 access points
• over 15 old stove pipe applications terminated and introducing some special collaboration services.

The lessons learnt were positive since reserve officers both used and operated the TOC-system first time:

• those processes that were staffed with off duty and on duty shifts suited well for virtual CP consept since the CP site changed every time the shift changed.
• The technical support each individual transferring user needed was striped to online support
• The establishment time needed for each user to gain access and start working with operational picture and planning process was eliminated to minutes from arrival to CP site.
• Pure IT based staff work is possible but it demands all documentation in electronic format
• The security can be adhered while working with both secure and restricted information systems over public access network
• The collaboration enhanced with VoIP-telephone and virtual white board is enabling an effective virtual staff work among distributed command post elements.

The second cycle gave approval enough to speed up the spiral development and introduce process enhancements for virtual staff work and mobile access. Major doubts for detaching services from users were overcome and the easy admin of workstations while moving from site to site did raise some hopes.

Third Spiral Cycle – Service Operation

The third cycle is divided into several lines of development. Process line is concentrating in operational planning process. Command Post line is concentrating in mobility and better ergonomy in work site. IT-line is concentrating in portal development that supports processes and mobility. Additionally each line has a number of subcycles.

Each line is divided into several subcycles that follow each other and support subcycles in other lines. This did raise the demand for syncronization and management through the total cycle.The lessons learnt phase is not yet fulfilled, but the results from subcycles are as follows:

• Internet-services can be stripped and formed so that the risk for information security lessens
• User is able to change terminal but maintain ones service profile by smart card authentication
• A planning process can adhere virtual command post
• TETRA 25 system can be used for light mobile C4I system access network
• A staff work site can be transferable and able to sustain work over 12 hours per shift.

Fourth Spiral Cycle – Enhanced process

The fourth cycle is coming in the year 2004 and it will put all the subresults together to prove that several HQ´s can operate distributedly and maintain main processes. They can improve their staff work respectively and at the same time increase their survivability. The fourth cycle will consist of:

• Over 100 users distributed into tens of sites formed as CP-elements
• Over 30 different applications in use
• Planning process supported with portal workflow, decision flow and information flow.

RESULTS OF TOC SPIRAL METHOD

The TOC project has been funded in a traditional way. The budget for years 2001 - 2005 has been laid out in 1988. The project started with defined object but was reopened in the first year. The project was given a task to think the whole concept from beginning and not necessarily as P3I approach. The first spiral was very careful minimizing all risks. It build a great confidence since the second cycle aimed to serve a very important exercise. After success, all levels of concept got speed into their cycles and new innovation was introduced specially at the process level.

Now the project is proceeding at every level. IT was the most effective during the first two cycles, but now the process level is to create the most results and enhancing C4I in very profound manner – changing the method of staff work itself and not only the tools around HQ.

In spite of the initial settlement of TOC project, budget has held, cycle objectives have been adjusted according feedback from CPX-tests. The project is going to reach results not imaginable in the definition year 1998 but keeping the budget and timetable as fixed.

ANALYSIS OF THE SPIRAL DEVELOPMENT METHOD

The Spiral Development method is very risk intensive way of produce a new system. It has a lot lower risk level when utilised in Pre Planned Product Improvement method. The risk is lower if project is possible to divide several subprojects, which are not that interdependent and may fail independently without risking the output of the whole project.

Although the TOC project managed to live with traditional budget plan, the funding is a major restrict to a cost-effective spiral project. As the experience drawn in the U.S. DoD shows, the funding must be evolutionary and allowing a wider scale of cycle durations.

The most effective spiral either asks for a group of very high professionals or a wide network of people in various fields that are able to change ideas and apply them non-orthodox way. As the network of people spreads, tools for collaboration, idea generation and project co-ordination are at higher stake.

-----------------------------------------------------------------------------------------------------------
References:

1 Joab Jackson: Pentagon backs spiral development. 06/09/03 News Week Tech Vol. 18 No. 5

2 Barry Boehm: “Spiral Development - Experience and Implementation Challenges”, CMU/ SEI-

2000- SR- 006 February 9- 11, 2000, Page 9.

3 Barry Boehm: Spiral Development: Experience, Principles, and Refinements

Spiral Development Workshop February 9, 2000

4 Joab Jackson: Pentagon backs spiral development. 06/09/03 News Week Tech Vol. 18 No. 5

5 Tim Spaulding: Budgeting for Evolutionary Acquisition and Spiral Development. LAI Plenary Conference, March 26, 2003 Massachusetts Institute of Technology

6 Kevin Gilmartin: SPIRAL DEVELOPMENT KEY TO EFX 98. Hanscom AFB Public Affairs, Mass (July 14, 1998)

7 Joab Jackson: Pentagon backs spiral development. 06/09/03 News Week Tech Vol. 18 No. 5