ACHIEVING MISSION ASSURANCE - Raytheon

More documents

Recommendations

Info

Feature Applying Mission Assurance Attributes to Net-Centric Architectures Net-Centricity is a foundation of the Global Information Grid (GIG), an important architectural concept that enables information availability and service sharing among various customer user communities — and one that critically impacts Mission Assurance. Clearly communicating the concept of the GIG and explaining how net-centric architectures (NCAs) provide Mission Assurance (MA) has historically been a struggle and is frequently the subject of much confusion and debate. Eliciting concrete definitions of these concepts, along with examples to provide better understanding, is highly desirable. Even more desirable would be the development of a process that demonstrates their meaning and value for the entire Raytheon engineering community developing NCAs. Accordingly, at Raytheon’s 2005 SETN/SWTN (Systems Engineering/Software Engineering Technology Network) Workshop held this past September, the NCA Technology Interest Group (TIG) and the Architecture Process TIG jointly recommended a special TIG project. This project would identify and assess the quality attributes and particular architectural features of NCAs that improve both the development efficiency and quality of those architectures that must support MA. The project would first develop a simple process framework to aid in the desired assessment. The Raytheon Technology Networks approved the project in October 2005. This article provides an overview of the project along with accomplishments to date and a brief description of future plans. Project Overview The project strategy is to select and use a candidate, representative net-centric system architecture to provide a useful context for gauging its impact on MA. The project plan then calls for the selection and use of a methodology (e.g., the Architecture Tradeoff and Analysis Method ® (ATAM ® ) or the Zachman Framework, among other possibilities) to help assess and define the 20 2006 ISSUE 1 RAYTHEON TECHNOLOGY TODAY selected NCA’s ability to support Mission Assurance. In particular, the project seeks to investigate specifically chosen quality attributes related to MA — including availability, modifiability, performance, security, testability and usability — to identify, capture and select those features such as design patterns, heuristics and standards of NCAs which best support MA. Phase 0 Partnership & Prep Phase 1 Initial Evaluation Phase 3 Follow-up Present the ATAM Presentation The end goals of the project are to: develop recommended approaches for identifying MA-related characteristics (i.e., attributes) for NCAs; identify MA-related architectural constructs for incorporating those attributes in NCAs; describe recommendations for capturing MA-related constructs in standard architectural documentation artifacts (e.g., ATAM templates, DoDAF views); and describe the selected methodology and its application in developing architectures. It should be noted that assessing the selected architecture itself (i.e., determining the specific architecture’s adequacy in addressing MA attributes) is not a particular goal of the project, but merely a means to an end. The results of the assessment, however, may be useful to the selected architecture’s program. Project Accomplishments The project first selected a candidate net-centric architecture from an ongoing Raytheon project to serve as the notional example for the assessment. (Due to customer proprietary reasons, the details of the project are not disclosed here.) A ATAM ATO-Lite Exchange understanding about ATAM and eval process Present the Business Drivers Present Architecture Identify the Architectural Approaches Generate the QA Utility Tree Analyze the Architectural Approaches Investigation (evaluation and architecture teams Brainstorm & Prioritize Scenarios Analyze the Architectural Approaches Present the Results Testing (eval, arch & stakeholder teams) Produce final report Reporting Phase 2 Complete Evaluation variety of factors was used to select the architecture, including its size (i.e., neither so small that its assessment would be trivial nor so large that it couldn’t be assessed within the project’s cost and schedule constraints), availability of architectural information and access to program personnel. Present the ATAM 1/2 HR - ST Figure 1. Evolution of ATM process into ATO Lite process Present the Business Drivers Presentation Identify the Generate Architectural the QA Approaches Utility Tree Investigation (evaluation and architecture teams Brainstorm Analyze the & Prioritize Architectural Scenarios Approaches Testing (eval, arch & stakeholder teams) Present Architecture Present the Results Reporting Next, the project determined the assessment methodology to be used; namely, an “abridged” version of ATAM. ATAM was developed by the Software Engineering Institute (SEI) as an extensive, robust architecture evaluation methodology to determine a software architecture’s suitability for its intended purpose. In essence, ATAM examines the adequacy and consequences of architectural decisions as they relate to the program’s quality and business goals. Note that while the SEI does not publicize ATAM’s use for system architecture evaluation, our team found it to be directly applicable to the aims of our project. Since assessing the candidate architecture wasn’t an end goal of the project, we identified a subset of ATAM activities that would be sufficient for the project’s purpose. This subset is a less formal, less thorough, and less time- and cost-intensive execution of ATAM. As such, we focused squarely on Mission Assurance-related concerns. One of the benefits of this “abridged” version of ATAM, hereafter referred to as “ATO (Architecture Trade Off) Lite,” is that it can be applied as part of the initial architecture development (i.e., in a “forward looking” fashion, as opposed to evaluating a generated architecture in a X Review materials offline - 2 hour meeting to clarify Start with check list
Figure 2 “backward looking” fashion). Figure 1 provides an overview of the full ATAM process and how we evolve it into an ATO Lite process. We estimate that applying the ATO Lite process requires a lot less effort than that required for a complete ATAM assessment, yet (importantly) we believe that it still provides a significant portion of the value that a complete ATAM assessment offers. We do so by eliminating the formality and scope of the meetings and documentation and focusing on generating the utility tree, quality attributes and scenarios. Using the selected architecture’s business drivers, the project identified ATAM Utility Tree-derived quality attributes and their major concerns. (In this context, the term “concerns” refers to specific focus areas within a quality attribute, while “business drivers” are derived from customer-level documents such as business goals and mission objectives). The result is shown in the upper-left part of Figure 2, which depicts a snap shot of the “Modifiability” quality attribute and identified concerns. This example for one particular quality attribute demonstrates the process; it is, of course, necessarily repeated for each quality attribute of interest. Each quality attribute is then broken down into concerns as applicable to the subject mission, (Figure 2, upper right). One or more scenarios are then developed to further demonstrate a concern. These concerns are eventually analyzed and assessed in detail with the help of a template (Figure 2, lower right). A “scenario” is a specific, implementable example situation that demonstrates a specific concern. Assessment is done at the scenario level. In software engineering terms, a scenario is akin to a use case; in tactical terms, it has the flavor of a tactical situation (TACSIT). Conclusion and Future Plans As of this writing, the project’s remaining tasks include: conducting the assessment using the ATO Lite process; identifying recommended architectural constructs (e.g., design patterns, heuristics and standards, among other possibilities) to support Mission Assurance in NCAs; and completing the documentation of the project’s results and presenting them at Raytheon’s 5th Annual Systems and Software Engineering Symposium, March 28–30 at the Marriott Tech Center in Denver, Colo. Naturally, this special TIG project has had a limited budget and schedule. Therefore, with additional time and budgetary resources, the results of the project could certainly be refined and extended. For example, it would be useful to apply the project’s approach to a second candidate architecture (perhaps one from a slightly different problem and customer domain) to refine and extend the set of quality attributes and concerns and the recommended architectural constructs. In addition, an excellent follow-on activity would be the actual development of the design patterns, heuristics and standards that the project identified as reusable artifacts in order to make them available for use on multiple programs. We’re also hopeful that, as a result of this project, other programs may use the methodology and project results to help assess their own architectures, thus enriching and maturing the methodology even further. Jon Edmondson and Edwin Lee Co-Chairs, Net-Centric Architectures Technology Interest Group jon_s_edmondson@raytheon.com ewlee@raytheon.com Resources 1. Clements, P.; Kazman, R.; & Klein, M. Evaluating Software Architectures: Methods and Case Studies, Boston, MA, Addison-Wesley, 2002. 2. Bass, L; Clements, P.; Kazman, R.; Software Architecture in Practice, Boston, MA: Addison- Wesley, 2003 3. Class Book, ATAM Evaluator Training, Carnegie Mellon, SEI, 2005 4. DoD Architecture Framework, Version 1.0, Feb, 2004. DoD Architecture Framework Working Group 5. The Open Group Architecture Framework V.8.1, Enterprise Edition, The Open Group 6. Class Book, Implementing and Managing Enterprise Architecture, Barnett Data Systems and The Zachman Institute for Framework Advancement, April, 2004 7. A Framework for Information System Architecture, by J. A. Zachman, IBM System Journal, Vol. 38, No 2&3, 1999 Reference Web Links Raytheon Net-Centric Architecture TIG: http://home. |ray.com/rayeng/technetworks/setn/networkcentric.htm Raytheon Architecture Process TIG: http://home.ray. com/rayeng/technetworks/setn/arch_process.htm Software Engineering Institute ATAM: http://www.sei.cmu.edu/architecture/ata_method.html The Software Engineering Institute (SEI) is a federally funded research and development center sponsored by the U.S. Department of Defense and operated by Carnegie Mellon University. RAYTHEON TECHNOLOGY TODAY 2006 ISSUE 1 21
Page 1 and 2: technology today HIGHLIGHTING RAYTH
Page 3 and 4: technology today is published quart
Page 5 and 6: Assured Policy/Decision Support Ass
Page 7 and 8: and intuitive to the average system
Page 9 and 10: satisfied. The decomposition of a w
Page 11 and 12: in theory, make it more robust. Fro
Page 13 and 14: Figure 2. Integrated health managem
Page 15 and 16: inserted into the system through sp
Page 17 and 18: Technology Transition Strategy The
Page 19: Figure 2. UPDM standards context Gr
Page 23 and 24: onTechnology IBM Cell Processor Pav
Page 25 and 26: onTechnology Aerothermal Capability
Page 27 and 28: Processes Design for Six Sigma: A T
Page 29 and 30: Figure 1 Raytheon Vision & Strategy
Page 31: People ANNOUNCING THE 2005 EXCELLEN
Page 34 and 35: U.S. Patents Issued to Raytheon At
Page 36: Future Events 18th Annual Systems a

ACHIEVING MISSION ASSURANCE - Raytheon

Create successful ePaper yourself

Delete template?

Save as template?