Process Improvements for Capability Maturity and Tool Synergy

Joe Schartman

Joe.schartman@SCalLinuxSystems.com

Summary:

This report is a post-hoc white paper evaluation of the processes that are followed by many major aerospace and defense contractors. Most of these companies are following the CMMI process at level 3+ so this white paper will focus on the best practices and process improvements. Most projects worked in research and development (RAD) groups are not following the CMMI process because the work is either non deliverable or prototype projects that can not afford the expense of following the CMMI process. This paper proposes many process improvements for RAD work. These improvements include some of the best practices for more closely following CMMI processes. It is beneficial to determine which practices, process improvements, and tools can be applied to the research and prototypes produced for RAD. These benefits should also help the CMMI process that companies are following and offer more advantages for improving the current common processes and tools.

This report is directed to project management, system architects and the software engineering process groups (SEPG). The intent is to advise how system work products produced by RAD can help improve and optimize the current CMMI process by providing more reusable components and best practices.

Table of Contents

Introduction …............................................................................... 3

Choosing a CMMI model representation....................................... 4

Maturity and Compliance Levels................................................... 5

Appraisals and Audits………………............................................. 6

Additional Process Frameworks and Environments....................... 6

DoDAF Framework

DIICOE Environments

Process Improvement Benefits….................................................... 9

Tool Recommendations…………................................................. 11

Process Improvement Tools

RTOS Choices

Modular Function Block Programming

Software Package Managers

Agile CMMI Maturity................................................................... 13

Research & Development (RAD) Project Life Cycles.................. 14

Recommended Process Improvements for RAD Projects.............. 15

Conclusion ………......................................................................... 15

References ………....................................................…….............. 18

List of Figures:

TABLE 1 Comparison of CMMI Model Representations ………... 5

TABLE 2 Mapping DoDAF Views to UML Diagrams …............... 7

FIGURE 1 DIICOE System Layers..................…............................ 9

Introduction

The Capability Maturity Model Integrated (CMMI) is a standard for rating the capability of process development areas of organizations. These capabilities include planning, engineering, managing, and maintenance. There are five levels of the CMMI model for rating an organization. Higher levels indicate an organization’s ability to produce more predictable, effective, measured, and controlled software and system deliveries. Organizations can apply the CMMI process using either a continuous representation or a staged representation. The process tools and appraisals are important considerations for improving an organization’s process model. Understanding the CMMI process and tools is important for all organizations. Large organizations often plan to reach the CMMI level 5 to help win contracts and increase profit and capability. Small organizations often consider following CMMI areas that would benefit a tailored process and system development.

CMMI is a set of models to help define process goals, priorities, establish guidelines for the process, and provide a guide to appraise current practices. CMMI consists of four disciplines models and two representation models. The two representation models are staged and continuous. The representation models allow organizations to have two improvement options. The content of both models are the same, but the data is presented in different ways. CMMI also includes an acquisition module, two appraisal methods, and four training courses. CMMI models need integrated compliance from the following organizational groups: systems and software engineering, product and process development, and subcontract management. The SEI CMMI Website (2006) explains all of these statements in detail.

As Shrum (2000) explained, CMMI models are structured by process areas, which describe the practices and goals that organizations use and plan, respectively. These process areas can be organized into two different representations, a continuous or staged, and these representations are discussed below.

Research shows (King, 2003) that all organizations will benefit with fewer defects and greater cost savings by operating at high CMMI maturity levels. Major aerospace and defense contractors need to operate at high CMMI since many of the current contracts now require such capability. The U.S. Missile Defense Agency's ground-based midcourse defense (GMD) required CMMI process for this projects prime contractor, The Boeing Company. Boeing also required CMMI process for its GMD subcontractors (Benson, 2005). These organizations have the process setup to operate at this level so the goals are continuous optimization and improvement. These goals involve using new tools, frameworks, environments, and process improvements. The remainder of this paper will discuss use of new tools, frameworks, environments and process improvements and how RAD project work can help to satisfy these goals by integrating this new technology with the CMMI process.

Choosing a CMMI model representation

CMMI defines two model representations, staged and continuous, which both cover the same process practices areas including requirements management, design, development, testing, configuration management, quality assurance, and integration.

The staged representation of the CMMI model measures process improvement according to maturity levels. The continuous representation of the CMMI model measures process improvement according to capability levels. Capability levels are process improvement capabilities within process areas.

The continuous representation is concerned with capability levels, while the staged representation is concerned with maturity levels. Six continuous representation capability levels (0-5) are measured against an organization's process improvements in a particular process area. Five staged representation maturity levels (1-5) are measured against the achievement of the goals for all the process areas in the respective maturity level. These capability or maturity measurements are performed during appraisals by outside consultants or internal organization auditors.

The continuous representation works best for most organizations CMMI process improvements since the staff can choose the process practices that best suit the current project requirements. The staged representation is followed by organizations that need to operate at a particular CMMI process maturity level required for contract deliveries. The continuous representation is a more agile representation since it allows organizations to be flexible following the process area practices during development, coding and testing that best meets the current project requirements. A good example for improving the process from level 3 to level 4 would use continuous additions to the metrics collection and analysis process until it is all quantitatively managed. Since the goal of higher CMMI level is an optimizing and improving process, both representations need to identify and integrate continuous process area improvements.

Shrum (2000) compares some of the advantages of using each model representation in Table 1. Shrum explains that the continuous improvement additions used for the continuous representation grants organizations explicit freedom for selecting the order to incorporate these improvements. The staged representation benefits a complete level by incorporating all the required improvements to each of the process areas. Shrum states that the continuous representation reflects a newer approach that does not yet have enough data yet to prove its return on investment (ROI). The staged representation positive ROI has been proven with a long history of case studies. Since a RAD group does not have to operate per CMMI levels, the best practices would be adding practices from different CMMI levels, such as configuration management, peer reviews for some of the work products, and a limited metrics collection and analysis for product development comparisons that would benefit future tool decisions.

TABLE 1 Comparison of CMMI Model Representations

Maturity and Compliance Levels

CMMI is based on maturity levels, while Defense Information Infrastructure Common Operating Environment (DIICOE) is based on compliance levels. CMMI process levels 1 to 5 indicate the maturity level that an organization follows for product life cycle capabilities. DIICOE implementation levels 1 to 8 indicate the operational cooperation, data sharing, and security that applications will follow on DIICOE computing environments.

There are four model areas that the CMMI process integrates. These areas include software engineering, systems engineering, integrated product/process development and supplier subcontract process management. An organization that operates at CMMI level 5 and delivers DIICOE compliant applications that that run on DIICOE computing environments can expect to have an improving process delivering minimal defect applications that are highly secure and highly reliable for mission and safety critical systems.

RAD project architects who produce work products targeted for defense applications need to consider using UML, DoDAF and DIICOE standards since these products will have better reusability and technology insertion into future contract programs thus help the overall CMMI process capability. The DoDAF and DIICOE standards are discussed in the Additional Process Frameworks and Environments section below.

Appraisals and Audits

The Appraisal Requirements for CMMI (ARC) method classes are a set of requirements for defining, developing, and using evaluation guidelines on CMMI processes. ARC was created from the CMM Appraisal Framework (CAF) to allow both the staged and continuous CMMI model representations. Existing CMMI models are used by appraisal teams to evaluate an organization’s processes. Appraisals are beneficial for determining the current organizational process maturity capability level for proposal or risk mitigation plans. According to CMMI Appraisals Requirements (2006) risk mitigation plans are beneficial for product acquisition, development, and monitoring plans.

The findings from appraisals, audits, and compliance tests should be analyzed for inclusion into RAD work products to help the organization strengthen is capabilities in weaker areas. If a RAD prototype for a network data application was found to be only DIICOE level 5 compliant but level 8 compliance is required for integration into a classified DoD network, then this RAD prototype could do further interface investigation and segmentation designing to allow future variants to increase to DIICOE level 8.

Additional Process Frameworks and Environments

DoDAF Framework

The Department of Defense (DoD) Architecture Framework (DoDAF) is a specification mandated for new DoD acquisitions and is resource-intensive. This specification is a model driven framework which defines systems views (SVs), operational views (OVs), and technical views (TVs). DoDAF is based on UML and it can be tailored to work well within the Capability Maturity Model Integration (CMMI) process.

As defined in the DoDAF (2006) an OV is “a description of the tasks and activities, operational elements, and information exchange required to accomplish DoD missions.” An SV is “a set of graphical and textual products that describes systems and interconnections providing for, or supporting, DoD functions. The SV associates systems resources to OV.”

Many of today’s systems are highly integrated, which greatly increases the overall complexity. These systems-of-systems (SOS) require compatible hardware, software and network protocols. SOS architectures require technical design specification frameworks and DoDAF was designed to satisfy these goals.

Simplistically, the OVs and SVs establish what systems must connect, and the SVs and technical standards view establish how systems must connect (Hamilton, 2006). From an engineering perspective, OVs are representations of requirements. The SVs describe how those requirements are implemented. DoDAF-compliant architectures constructed with this symmetry in mind have traceability between systems and requirements. (Hamilton, 2006)

DoDAF, like any architectural framework, requires a description language for implementing the architecture diagrams. UML is the most common description language used for DoDAF applications. Understanding both the DoDAF work products views and the various UML diagrams requires training and experience. Enterprise Architect is an excellent tool offered by Telelogic, which has the capability to create DoDAF work products views that are extensions of UML diagrams. A few of the DoDAF views to UML product mappings are listed in the TABLE 2 below (Kobryn & Sibbald, 2004).

TABLE 2 Mapping DoDAF Views To UML Diagrams

DIICOE Environments

Defense Information Infrastructure Common Operating Environment (DIICOE) is a framework that was created by the Defense Information Systems Agency (DISA) to manage set of cooperating computing networks. DISA wanted to enable its various Global Command and Control System (GCCS) networks to share date and be managed as a common environment. By 1998, GCCS was operational under the DIICOE environment and during the next few years hundreds of Department of Defense (DoD) systems were also updated to run under DIICOE. These systems included computers running Microsoft Windows, Sun Solaris, HP UNIX, and Linux for programmed under Army, Navy, Air Force, and Marine Corps. The DIICOE has been a tremendous improvement to the DoD capability since as Dr. Gregory Frazier (2001) explains “The DoD enterprise computing system is a system of systems (SoS) with information and services that are shared across enterprise boundaries.”

DIICOE is an integration framework, not a design framework like DoDAF. Developers follow the DIICOE segmentation rules to create applications that can be installed and run under DIICOE network machines. Frazier explains that these applications are designed to be modular, and scalable for distributed Command, Control, Computer, Communications, Intelligence, Surveillance, and Reconnaissance (C4ISR) DIICOE computer systems. These computer systems are now integrated environments that allow sharing data between the applications and networks and common management application program interfaces (APIs) for performing cross platform system administration and of COE applications.

DIICOE specifies applications as segments, which are similar to packages used for open source software. These segments are more than just software packages since the segments have to pass validation tests before system integration. This validation actually works like an integration test review since the format specifications need to be reviewed by integrators and validation is performed by the COEInstaller tool. This segmentation process also works as a coding standard since standard configuration management versioning, naming, and documentation is all required by the Integration and Runtime Specification (I&RTS). The level of compliance with the I&RTS determines the level of DIICOE applications. DIICOE systems use the COEInstaller tool for installing compliant applications on the target systems.

DIICOE systems have the following four levels of software: the kernel, the common support applications, and the infrastructure services. See FIGURE 1 DIICOE System Layers for an example. The kernel is common to every DIICOE computer and is the level above the associated operating system (OS). The kernel APIs offer common interfaces to the machine OS including most of the system administration capabilities. The common support applications are the computer desktop tools like email, word processors, and web applications. The infrastructure services offer general purpose utilities like development, database, web and file system tools.

DIICOE is similar to CMMI since it has compliance levels. Both of these process have levels where higher number indicate better compliance but DIICOE has 8 levels instead of 5 for CMMI. Higher levels of DIICOE indicate better cooperation and data sharing between the applications. DoD applications need to operate at a DIICOE level of 5 or higher since this will guarantee strict segmentation behavior and no security risk to other DIICOE applications. The DII Integration and Runtime Specification (I&RTS) should be consulted for segmentation and compliance details.

FIGURE 1 DIICOE System Layers

Process Improvement Benefits

Process Improvement will benefit all four of the CMMI integrated areas discussed in the above Maturity and Compliance Levels section. Each of these areas needs to use common practices and procedures to help predict and improve the system quality. An organization use of common practices and procedures for each of the four areas is necessary to achieve CMMI rating at one of five maturity levels including: Initial, Managed, Defined, Quantitatively Managed, and Optimizing. The following product and software benefits will result from using the listed CMMI model development practices:

• Improved predictability will result to schedule and budget by developing software using organization coding standards and methodologies. Organization product reviews of developed work products following the code and design standards will result in consistent work products and process metrics.

• Improved cycle time benefits will result from long term practice of the CMMI process. Organizations will increase CMMI levels over years of development practice, which will lead to an optimizing and improving process operating at CMMI level 5. According to Pfleeger (2006) these optimized processes will benefit from fault prevention, technology and process change management.

• Improved cycle time benefits will include a reduction in integration and test time with greater success rate. Fewer product defects, better design work products using reused design and software modules will increase the success rates. These successes will also involve improved integration and interaction within the engineering functional areas. These improvements will start to be beneficial for organizations operating at CMMI level 2 using repeatable planning, tracking, inspection and configuration management processes.

• Increased productivity will result from continual CMMI process practice. Code development techniques will improve with practice and by reusing prior produced software work products. Product reviews will become more efficient and defects will decrease. These product improvements will benefit with increased productivity and improved quality.

• Improved quality will result from more efficient product reviews with decreasing defects. The metrics from these reviews will be quantitatively measured and analyzed. This quantitatively managed process is common within CMMI levels 4 and 5.

• Increased customer satisfaction will result from these process and product improvements. This increased customer satisfaction will lead to more contracts, sales and profit.

• Increased return on investment (ROI) will result from the reusable work products and CMMI process productivity.

• Improved employee morale will benefit from the ROI and improved products since employees will probably get good pay increases, have better job security and feel more comfortable and less stressed out at the work place. Employee training programs are also required to operate at CMMI level 3 and will help to increase the staff morale and improve the staff capability.

• Use cases development and maintenance leads to most complete and functionally understood system.

An organization following the SEI CMMI process model using the practices described above will have continuous process improvement since management of these defined practices using metric analysis will lead to an optimizing process. The SEI CMMI Website (2006) lists the benefits as increased stability in management, system design, integration, risk management, and analysis. Improved predictability for schedules, budget, cycle time, productivity, quality, customer satisfaction, employee morale, ROI, and reduces cost of quality.

DoDAF system and operational views can be used with UML work products to greatly improve the design documentation. UML design documents can be forward engineering to code and then reverse engineering from code back to the design work products. This ability allows developments in either design or implementation to be updated into the current work products for time and cost savings. These improvements allow a more agile interactive approach to system development. DoDAF tools, like Telelogics Enterprise Architect, can generate system and operational view diagrams that map closely to UML work products.

Auto coding using module development with tools like Mathworks Simulink, can minimize the coding and unit testing project phases because the generated modules are guaranteed to be error free. This auto coding process thus saves both coding and testing efforts. These tools can also help improve the component reusability repository for an organization.

RAD project groups should gain experience using UML, DoDAF and auto coding tools since the work products will add to the organization’s reusable component repository and gain experience using process improvement tools for future projects. The next section will discuss and recommend several of these tool options.

Tools Recommendations

Tool choices are very important factors for system development and need to be considered based on the development host and target hardware and project budget. Training should also be provided for tools used by an organization. A few of the common tools selections used by major defense contractors are discussed below.

Process Improvement Tools

Implementing a metrics database with analysis tools is very important for providing an organization tracking and progress improvement capabilities. The metrics should be populated in the database after they have been collected and confirmed from process activities like work product inspections and trouble and change reports. Analysis tools should provide querying capabilities, report generators and project summaries. The metrics database should contain data for all the organization projects.

Some other process improvement tools that can be very helpful include:

• CostXpert - Parametric estimation model using the COCOMO-II algorithm.

• The_Count - Provides a means for projects to consistently determine size data for use in metrics. Most programming languages and scripts are handled.

• SCCS, ClearCase and SourceSafe – Configuration management tools used for software work product versioning. ClearCase is the most powerful of the tools and recommended for large programs. SCCS and SourceSafe are the most popular configuration managers for unix and Microsoft platforms, respectively.

• GNU, RationalRose and Visual Platform – Code development tools. RationalRose is the most powerful of the tools and recommended for large programs. GNU and the Visual Platform are the most popular code development for UNIX and Microsoft platforms, respectively.

RTOS Choices

There are many excellent choices for real-time operating system (RTOS) development systems and the most popular commercial products today are from WindRiver and GreenHills. These commercial products are preferred by most large companies because they provide maintenance, support and training. WindRiver provides the VxWorks Tornado and Workbench products for RTOS embedded system application development of custom boards, processors, and component chips. Tornado and Workbench simplify the process of writing embedded applications for commercial and custom target hardware. These products both supply boards support packages (BSPs) for many of the common embedded processors and provides a project facility, which simplify the process of making custom device drivers and application code. The GreenHills Integrity RTOS is one of the main competitors to VxWorks. Integrity is also popular for most of the same reasons.

The other popular option for RTOS development is using the free open source software (OSS) Linux kernel and development system. This option requires more software development expertise since the programmers need to build and maintain host and target cross development systems and build the desired embedded target application. The OSS choice also required keeping up with source releases and rebuilding all the development and application code with new source software patches.

Modular Function Block Programming

MathWorks MATLAB Simulink tool provides for modular programming using an auto coding process. Simulink can be used for development using modeling and simulation and can produce embedded target applications. This development allows development of high level module block to create architecture block diagrams. These diagrams can then be auto coded into documented C code thus bypassing the coding and unit testing development phases.

Holland (2002) explains Simulink enables a single environment throughout projects, with the option to automatically deploy algorithms and applications as C/C++ code, Excel add-ins, and COM objects.

Modular programming modules are also referred to as function blocks or components. Component based software (CBS) tools are also very popular in the industrial controllers and instrumentation industry. CBS provides function blocks as components of the device firmware. These components can be selected from function block libraries to build into or download to an embedded application.

Lewis (2002) explains that system design will become the process of software component selection, configuration and interconnection, just as much as electronic hardware design is now primarily concerned with the selection and interconnection of IC chips.

The industrial community has incorporated function block software components into many of the leading tools and development platforms. These components, tools and platforms have benefited with improved software productivity by re-using standard solutions. Another benefit is the improved design flexibility using plug-and-play software and devices from different vendors.

Software Package Managers

DIICOE is concerned with designing specification segments for implementation partitions much like OSS packages use packaging for applications. DIICOE requires developers to build application segments following the I&RTS specification. The COEInstaller installs and manages DIICOE applications. OSS applications use several different package formats like the Red Hat package manager (RPM). Software packaging is a very wise choice for providing a common installation configuration and runtime management capabilities. RPM and Debian packages are common for the UNIX/Linux world, DIICOE segments are required for DIICOE systems and for Window systems the MSI package manager uses MSI files. Software packages should be developed for installing applications since this best practice will allow for repeatable installations.

Agile CMMI Maturity

CMMI capabilities of level 3 (L3) and level 5 (L5) organizations have significant maturity differences but can have similar performance benefits.

CMMI L5 involves an organization with improving process producing higher quality systems. These organizations use status tracking, configuration management and development environment tools that allow consistent and predictable development progress. These tools are used best by experienced engineers that are trained with regularity scheduled training programs.

An organization operating at CMMI appraisal L3 may actually operate at CMMI L5. Such an organization was comprised of bright engineers, who were well managed and operated with excellent communication. This organization’s process was a daily activity with all the reviews, status, and configuration management work products in a constant state of recording and metrics collection. This organization also performs daily meetings and reviews using open communications, which resulted in a very successful agile team with positive results.

Another company operating at CMMI appraisal L5 had all the process activities defined and setup for on line tracking and reviewing capabilities. This organization did not use these tools and processes on a daily rate and that the on-line view cut down on the reviewing communications and staff learning interactions.

The capability differences between CMMI appraisal L3 and L5 can be significant but the quality of the software and system produced from a L3 organization can be better than from a L5 organization. This performance difference is explained in the below discussion of agile methods usage.

Agile methods help performance on large scale project developments. One such project was done in phased increments, which added functionality to each delivery. The phases actually overlapped such that phase 1 was in system test and integration phase while phase 2 was in the design additions and unit testing phase. Such incremental deliveries required a configuration management (CM) system that was able to differentiate many different components to the right build sets. Rational Clearcase was the CM tool used and it had superb configuration, viewing and reporting capabilities.

This project described above was actually rated at CMMI L3 but it performed as well or better than the other described project rated at CMMI L5. This is an example that a CMMI L3 process that uses agile practices with excellent communication can out perform another process running at CMMI L5.

All the CMMI L5 activities can be followed but if the organization is not actively using these managed and controlled status feedback then the process improvements promised for operating at L5 will not truly benefit the organization. Communication is the key ingredient that must be involved in these activities. Product review actions, lessons learned from metric analysis should be communicated to upper management in periodic program management reviews and process improvements should be directed from these reviews back into the process. This product lifecycle should be analyzed by metrics and improved by program management.

Research & Development (RAD) Project Life Cycles

Typical RAD projects include white papers, proposals, and prototype deliveries. These work products are not categorized as product deliverables because they are not contracted as operational system deliveries. This categorization results in these projects not following the company defined CMMI Level 5 process but rather a tailored product work cycle. This tailored process makes financial sense because RAD and prototype work is either company financed or small contract finances.

The two types of prototypes are exploratory and throwaway. The objective with exploratory prototyping is to work with the user to explore their requirements and deliver a final system. This approach starts with the parts of the system that are understood, and then evolves as the user proposes new features. Throwaway prototyping involves determining and developing better user requirements for defining the system. This approach concentrates on poorly understood components. Prototyping provides a very good user visibility of the product and a rapid initial operational capability. Possible disadvantages are that bad code can be developed, it can be difficult to manage, and it can be difficult to benefit future software. The goal with prototyping should be to develop exploratory system reusable work products using approved processes and tools.

The typical RAD project life cycle usually starts with a technology study or project prototype that leads to a white paper used as a proposal to be sent to potential customers. The proposal will often generate additional funds for a more detailed prototype or add on technology developments. In either case, it’s beneficial to have a system design that allows for modular extension and updates to the existing work product artifacts. For these reasons, UML is a preferred technology since the requirement use cases and the object orientated diagrams are very adaptable and maintainable. It is also preferred to use DoDAF system and operations views that correspond to the UML diagrams. A project that needs to generate both types of diagrams can choose a tool like Telelogic Enterprise System Architect that can generate both DoDAF and UML diagrams from the system database information. RAD projects should consider generation of work products that can be reused in the future. UML work products are currently the best practices since many tools can forward engineer the UML diagrams into several different high level implementation languages including C, C++, and Java. Many of these tools can also reverse engineer changes to the different high level implementation languages classes back into the UML design work products. Usage of such UML tools can save projects time and help keep the system design work products consistent.

Recommended Process Improvements for RAD Projects

The following practices, methods, work product, architectures frameworks, environments, and process improvement are suggested considerations for RAD project work products:

• UML usage, at least use cases and class diagrams

• Informal peer reviews, formal reviews with metric analysis to expensive when not required

• Best practices and lessons learn logging for process improvements

• Common configuration management, need to save reusable work products

• DoDAF design methodology and DIICOE segment implementation for DoD applications

• Software packaging for installation and delivery consistency

• Common processes and tools based on development platform and target hosts. (Tool Recommendations and The Boeing Internal SEPG Website, 2006)

These recommendations will help to improve the current system development, provide testing and integration improvements, and help optimize the process for future programs. For quantitative management of these benefits, it will be necessary to measure the product inspection metrics achieved with these improvements against the baseline system metrics. This quantitative management leading to optimized process improvements will help an organization’s process to operate at a CMMI level 7 maturity levels.

The following RAD projects have been successfully completed contributing to the experience capability but really contributed reusable generic design components:

• Auto Coded Model (ACM) Flight Code

• Guidance and Pulpulsion (GAP) project

• Pluggable Network Interface Card (PNIC) project

Given time and available tools it would be beneficial to reverse engineer useful UML and/or DoDAF work products such as requirement use cases and object diagrams. It would also be beneficial to create generic software modules, functions, or classes to be archive into a configuration managed repository for future program reusability.

Conclusion

An agile process using iterative development cycles and XP development teaming can greatly benefit any organizations product lifecycles. These agile methods can help increase process improvements just as quantitatively management of process metrics improves the CMMI L3 to L5.

The future of systems development should integrate a mix of the current best practices in process and product development. This mix will include CMMI process levels using UML work products and DoDAF/DIICOE type frameworks and tools that will use integrated databases for generating multiple work product views. DoDAF system and operational views can be used with UML products to greatly improve the design documentation. UML forward and reverse engineering can help improve the agile interactive approach to system development. Auto coding using module development can help improve the software re-usability repository for an organization.

Benefits following the CMMI process:

• Reduction in integration and test time with greater success rate.

• Integration and interaction within engineering functions.

• Ability to apply engineering principles in software development.

• Return on investment (ROI) improvements.

• Increased stability in management, system design, integration, risk management, and analysis (SEI CMMI Website, 2006).

• Improved schedules, budget, cycle time, productivity, quality, customer satisfaction, employee morale, ROI, and reduces cost of quality (SEI CMMI Website, 2006).

The DIICOE emphasizes both software reuse and data reuse using interoperability for both data and software. The DIICOE benefits include:

• An architecture and approach for building cooperative and sharable system resources.

• An environment for sharing data between applications and systems (Frazier, 2001).

• A framework for supporting mission critical applications.

• A segment package definition for the installation and execution environment.

• A collection of DoD approved reusable software components and data bases (Frazier, 2001).

• A validation tool set for determining application DIICOE compliance.

• An installation tool for network and system application integration.

• A framework of Application Program Interfaces (APIs) for managing DIICOE components on multiple platforms.

The following are the best practice procedures for improving the development process:

• Analyze requirements and produce UML use cases for customer and developer communications.

• Determine if target architecture requires DIICOE environment and if the operating system requires a RTOS, UNIX, Windows, or combinational platform.

• Determine if design methodology can afford UML work products and tools.

• Determine if design methodology requires DoDAF.

• Determine design tools and programming languages based on current experience.

• Determine if CMMI processes are required and if so then what level.

• Based on above decisions determine a master program schedule including milestone and support staff plans.

• Plan to perform milestone reviews, configurations, and audits with feedback to program management.

• Determine if an agile or extreme development effort will benefit delivery and if so then identify top priority system items for an incremental life cycle and repeat step 7 for each project increment.

References:

Artifacts for Agile Modeling(n.a). The UML and Beyond. Retrieved Jan 25, 2006 from: http://www.agilemodeling.com/essays/modelingTechniques.htm

http://www.irconnect.com/noc/press/pages/news_releases.mhtml?d=91034

Benson, M. (2005). Northrop Grumman Plays Critical Role in Successful Missile Defense Test. Retrieved March 3, 2006 from: http://www.irconnect.com/noc/press/pages/news_releases.mhtml?d=91034

Carnegie Mellon Software Engineering Institute (SEI) (n.a). CMMI Appraisals Requirements. Retrieved March 3, 2006 from: http://www.sei.cmu.edu/publications/documents/01.reports/01tr034.html

Favre, Martinez and Pereira. (2003). Forward engineering and UML: from UML static models to Eiffel code. Retrieved Jan 26, 2006 from:

http://portal.acm.org/citation.cfm?id=953202

Frazier, G (2001). The DII COE: An Enterprise Framework. Retrieved from:

http://www.stsc.hill.af.mil/crosstalk/2001/10/frazier.html

Hamilton, J (2006). DoDAF-Based Information Assurance Architectures. Retrieved Feb 13, 2006 from: http://www.stsc.hill.af.mil/crosstalk/2006/02/0602Hamilton.html

Holland, K. (2002). MATLAB and Simulink updated. Retrieved Jan 26, 2006 from:

http://www.embedded.com/story/OEG20020923S0049

King, J. (2003). The Pros & Cons of CMM. Retrieved March 3, 2006 from: http://www.computerworld.com/printthis/2003/0,4814,87882,00.html

Kobryn, C. & Sibbald, C. (2004). Modeling DoDAF Compliant. Architectures. Retrieved Feb 16, 2006 from:

www.uml-forum.com/docs/papers/White_Paper_Modeling_DoDAF_UML2.pdf

Lewis, B. (2002). IEC 61499 Function Blocks: A new way to design control systems?. Retrieved Jan 24, 2006 from: http://www.manufacturing.net/ctl/article/CA206056

Pfleeger, S. and Atlee, J. (2006). Software Engineering, Theory and Practice, 3rd ed. N.J. Printice Hall.

SEI CMMI Website (n.a). Retrieved March 3, 2006 from: http://www.sei.cmu.edu/cmmi/

Shrum, S. (2000). Choosing a CMMI Model Representation CrossTalk — The Journal of Defense Software Engineering. Retrieved Feb 19, 2006 from: http://www.stsc.hill.af.mil/crosstalk/2000/07/shrum.html

The Boeing Internal SEPG Website (n.a). Retrieved Feb 24, 2006 from:

http://webanc.ana.bna.boeing.com/engr/SOFTENGR/sepg/

http://webanc.ana.bna.boeing.com/engr/SOFTENGR/sepg/SPM.HTM