Download - Royal Australian Navy

More documents

Recommendations

Info

Developing Capability Definition Documents SEA 1442 Phase 3 is an endorsed project and the Integrated Project Team (IPT), including members from Capability Systems, are developing the initial version of the capability definition document suite for the Phase 3 request for tender (RFT). The suite includes the Operational Concept Document (OCD), Function and Performance Specification (FPS) and Test Concept Document (TCD). To provide the Commonwealth with diversity in approach to the MBCIS solution, three independent prime system integrators were engaged early, yielding significant benefits for the Commonwealth as insight into the range of problems that could result from the development effort was gained. The SEA 1442 IPT team will consolidate the capability definition documents with stakeholders from DNC4ISREW, Force Element Groups (FEG), System Project Offices (SPO) and other RAN agencies into a capability baseline that will form the basis of a contract between Capability Systems and DMO. The DMO will use these documents for the contract baseline for tender activity. Systems Engineering Issues The DMO’s Capability Definition Documents Guide (CDDG) provides significant advice concerning the content of the OCD, FPS and TCD, the applicability of the various Defence Architecture Framework (DAF) views and an indication of the system engineering approach that must be followed to ensure stakeholder needs translate into effective capability. The IPT is maintaining the consistency of the various DAF views to completely describe the system by managing changes as they occur. Often, views are generated in Word or PowerPoint formats and require a great deal of effort to manually maintain consistency once changes are made. This ‘engineering by Microsoft Office’ approach is considered inadequate for the specification of complex systems such as the SEA 1442 Phase 3 MBCIS. The complexity of the Phase 3 MBCIS stems not only from the technology involved but the potential number of other systems to which it interfaces. While the CDDG provides information about the content of the DAF views, it does not provide guidance about how the views should be kept holistic and complete. A robust and clearly articulated system engineering process in the context of a C4ISR (Command, Control, Communications, Computers, Intelligence, Surveillance and Reconnaissance) framework is required to guide systems engineering efforts within the project office and maintain the integrity of the system model being developed. For this reason, the project office decided to integrate a systems engineering standard into the foundation set out by the CDDG for the development of the capability definition documents. By mandating a more rigorous process that details what and how tasks such as requirements and functional analysis are implemented, those working on the project are better guided in producing a suite of mutually consistent documents with improved integration. The choice of which standard to integrate into the process was determined on basis of the standard’s quality, detail and popularity in Defence industry, as outlined below. SE Standards There are many standards applicable to the engineering of complex communications systems, written by several global authorities. One of the standards considered was the Electronics Industry Alliance 632 (EIA- NAVY ENGINEERING BULLETIN SEPTEMBER 2003 632:1998), identified by the ASDEFCON(SM) template. It is an engineering policy standard requiring a complete and integrated technical effort from identification of need through to disposal. Oriented towards control and surveillance by the customer, its principle value is contained more in the guidance associated with the 33 abstract requirements than the description of recommended engineering processes. In contrast, the Institute of Electrical and Electronic Engineering 1220 standard (IEEE 1220:1998) is similar to the EIA- 632 but details systems engineering processes and its application throughout the system life cycle. It defines an engineering model involving numerous processes and associated planning that comply with the requirements of EIA-632 and emphasize verification and validation. Each analysis/verification loop forms a phase of the overall process. This standard was selected because it contained detailed content, which suited the SEA 1442 Phase 2B project definition study and the relative immaturity of the processes within the project office. It is anticipated that as the project office’s capabilities mature, the less restrictive EIA- 632 standard will be utilised for controlling engineering efforts in the SEA 1442 Phase 3 acquisition. Process The systems engineering process (SEP) defined in IEEE 1220 contain three phases: requirement analysis/verification, functional analysis/verification and design synthesis/verification. Each phase may be iterated many times during system specification to ensure validity and consistency of the resultant requirement, functional and logical baselines. A simplified overview of this process is shown in Figure 2. 71 Broadly speaking, two iterations of the entire IEEE 1220 SEP will be conducted during the development of the SEA1442 capability documents, at two levels of detail. In the first iteration, the OCD and TCD are developed in parallel, using as inputs all the draft documents created by the collaborative effort with contractors mentioned earlier and further stakeholder engagement by the project office. This iteration codified the highlevel requirements of the warfighter, and sketches out the first few levels of the functional and logical hierarchy of the system. On completion of the OCD, the FPS is developed using a second major iteration of the IEEE 1220 SEP, translating the requirements of the OCD into technical specifications at far greater detail and filling out the lower levels of the hierarchies. These major iterations are shown in Figure 3. The CDDG guidance was extended by mapping it onto the SEP defined in IEEE 1220. The mapping involved relating all parts of the CDDG to IEEE 1220 processes and the various sections of the capability definition documents to process outputs. The mapping created breakpoints in the development process of the definition documents where quality and consistency between the various sections of the OCD, FPS and TCD could be checked. As a consequence of explicitly embedding the iterative nature of the SEP into the CDDG, conflicts or variances discovered at each phase of development trigger another iteration of a phase in a controlled manner in accordance with the IEEE 1220 standard. This approach is in contrast with the CDDG, where updating the documents on receiving feedback is considered nearer the conclusion of the development process. The development of the integrated development process
72 NAVY ENGINEERING BULLETIN SEPTEMBER 2003 FIGURE 2: SIMPLIFIED SYSTEMS ENGINEERING PROCESS FROM IEEE 1220 highlighted the importance of a cohesive and integrated approach to analyzing and specifying requirements. It identified the need to greatly reduce exposure to risk during architectural comparison, selection and development, particularly during the earlier concept definition stages in the exploration of mission need and benefit, and the development of mission concept and operations. The CORE integrated database, together with its specialized C4ISR schema has been mandated to capture systems, operations and design elements in a common data repository. The development process was extended to detail how data would be entered into the database using the special semantics of the C4ISR schema that relate operational and system architectural domains. As the system engineering effort progresses through the IEEE 1220 defined phases of (operational) requirements analysis, functional analysis and synthesis, requirements and function/performance specifications are merged into the CORE repository’s model at everincreasing levels of detail, as shown in Figure 4. The CORE tool allows the requisite DAF views in the CDDG to be automatically generated and updated, removing the need to redraw them on modification, which improves project office efficiency. The use of the database gives the project office far greater control of the system model being developed, as the elements, relationships and attributes of the system within and between operational, system and functional domains are tracked automatically. With the system model complete, the OCD, FPS and TCD, complete with required DAF views may be generated from the CORE database using existing or modified scripts, ensuring tightly integrated definition documentation of the desired system and improving overall document integrity. Conclusion Building on the foundation of the Capability Documents Development Guide (CDDG), the SEA 1442 project office is actively reducing risk by explicitly integrating strong systems engineering processes of the IEEE1220 standard and powerful software tools into the development of mutually consistent and robust capability definition documents. These documents will form the basis of the project office’s Request for Tender. Further details including the SEA1442 OCD, FPS and TCD are located on the project website on the DefWeb. 1 From ‘Systems Engineering Fundamentals’, Defense Acquisition University Press, January 2001, Figure 1-3. 2 From ‘Systems Engineering and Core®: A Natual Approach to C4ISR’, Figure 3, Vitech Corporation, 2002. About the Author: Mr. Lindeyer joined DMO in January 2003 after five years as a software engineer. He has degrees in engineering and science and shall complete an MBA this year.
Page 1 and 2:
NAVY ENGINEERING ISSUE 5 SEPTEMBER
Page 3 and 4:
2 NAVY ENGINEERING BULLETIN SEPTEMB
Page 5 and 6:
Page 7 and 8:
Page 9 and 10:
Page 11 and 12:
10 NAVY ENGINEERING BULLETIN SEPTEM
Page 13 and 14:
Page 15 and 16:
Page 17 and 18:
Page 19 and 20:
Page 21 and 22: 20 NAVY ENGINEERING BULLETIN SEPTEM
Page 71: 70 NAVY ENGINEERING BULLETIN SEPTEM
Page 77: 76 NAVY ENGINEERING BULLETIN SEPTEM
show all

Download - Royal Australian Navy

Create successful ePaper yourself

Delete template?

Save as template?