JOGSE GRAND SYSTEMS DEVELOPMENT TRAINING PROGRAM OVERVIEW 0900 09-01-2010 JOG SYSTEM ENGINEERING GRAND SYSTEMS DEVELOPMENT TRAINING PROGRAM JOGSE GRAND SYSTEMS DEVELOPMENT TRAINING PROGRAM OVERVIEW c JOG System Engineering

c JOG System Engineering Agenda Introduction Proposed program description Systems management overview Systems requirements overview Systems synthesis overview Systems verification overview Discussion c JOG System Engineering

c JOG System Engineering Who Is Jeff Grady? CURRENT POSITION President, JOG System Engineering System Engineering Assessment, Consulting, and Education Firm PRIOR EXPERIENCE U.S. Marines General Precision, Librascope Div Customer Training Instructor, SUBROC and ASROC ASW Systems Teledyne Ryan Aeronautical Field Engineer, AQM-34 Series Special Purpose Aircraft Project Engineer, System Engineer, Unmanned Aircraft Systems General Dynamics Convair Division System Engineer, Cruise Missile, Advanced Cruise Missile General Dynamics Space Systems Division Engineering Manager, Systems Development Department FORMAL EDUCATION SDSU, BA Math; UCSD, System Engineering Certificate; USC, MS Systems Management and Information Systems Certificate INCOSE First Elected Secretary, Initial Journal Editor, Fellow, Founder, ESEP AUTHOR System Requirements Analysis (2), System Integration, System Validation and Verification, System Engineering Planning and Enterprise Identity, System Engineering Deployment, System Management, System Synthesis Your instructor’s background has included 30 years of experience in industry working as an engineering manager, system engineer, project engineer, field engineer, and customer training instructor. The ten years he served in the Marines was primarily related to the logistics field involving radio maintenance in ground aviation and aircraft squadrons and training. Currently, he operates a system engineering consulting and training firm. The text material used in the program is based on the content of five books published by McGraw-Hill and CRC Press. This material is constantly evaluated and upgraded for program purposes. c JOG System Engineering

c JOG System Engineering JOGSE Client Base c JOG System Engineering

c JOG System Engineering System Life Cycle 2 3 4 1 c JOG System Engineering

c JOG System Engineering The JOGSE Grand Systems Development Training Program Four-Course Certificate Program Systems Management Systems Requirements Systems Synthesis Systems Verification Grand Systems = Each enterprise program integrating and optimizing at true system level (product and process) while the enterprise integrates and optimizes across the programs. c JOG System Engineering

Possible Program Electives Systems Sustainment Systems Effectiveness 1 (Reliability, Availability, and Maintainability) Systems Effectiveness 2 (Systems Safety and Human Engineering) Systems Effectiveness 3 (Systems Security and Privacy) Control Systems Theory Operations Analysis System Simulation Universal Architecture Description Framework Information Systems Development Using DoDAF c JOG System Engineering

c JOG System Engineering Program Documentation 1 3 4 2 JOG System Engineering 6015 Charae Street San Diego, CA 92122 (858) 458-0121 jgrady@ucsd.edu 51 52 53 54 55 56 57 Grand Systems Management Grand Systems Requirements Elicitation and Analysis Grand Systems Requirements Documentation and Management Grand Systems Synthesis Specialty Engineering Methods and Models Grand Systems Verification Grand Systems Requirements 58 59 5A 5B 5C 5D 5E Grand Systems Sustainment Systems Test and Evaluation Systems Simulation Computer Software Management Computer Software Requirements Computer Software Synthesis Computer Software Verification c JOG System Engineering

Recommended Program Cases c JOG System Engineering

INCOSE Mapping Requirements Course to INCOSE SEM c JOG System Engineering

Management Knowledge Grows & We Have Our Limitations EXPANDING KNOWLEDGE SPECIALIZATION EFFECTS MAN'S KNOWLEDGE Many thousands of years ago there was a time when every human on Earth could master all of the knowledge that mankind had amassed but it was not very much - and it was all survival oriented. Over time, man discovered that there were advantages if some members of their group concentrated on hunting and others doing farming work. Over a period of thousands of years, man has progressively accelerated this process of accumulating knowledge passing a point a very long time ago where the amount of knowledge available was greater than man’s individual capacity for knowledge because over this period of time man’s capacity for knowledge has not expanded significantly. The universal solution to this problem has been that individual humans engage in specialization of the knowledge they master. The reality is that no one can master all of man’s knowledge now or ever in the future. It is unlikely that Congress or the UN will pass a law or rule that there shall be no new knowledge. Knowledge has economic value in that the more knowledge brought to a problem, generally, the better the solution. So long as competition is an element of business, the advantage of a more powerful problem solving capability will continue to encourage expanding knowledge. IT WON'T ALL FIT! MAN'S LIMITATIONS c JOG System Engineering

c JOG System Engineering Management We Are All Specialists BREADTH OF KNOWLEDGE DEPTH OF KNOWLEDGE ALL KNOWLEDGE The editor of the McGraw-Hill “System Engineering Handbook” published in 1965, Robert Machol, said that man was T-shaped with respect to his knowledge. Through experience and education, a person masters some narrow but deep font of knowledge that they specialize in while also having broad knowledge that permits them to communicate with other persons. The latter commonly involves language, mathematics, and some science. The problem here is that, since no one knows everything, us specialists must communicate amongst ourselves about problems that require knowledge more extensive than any one person can master. Man has applied knowledge partitioning as a solution to the knowledge coverage problem which is only part of the whole solution. Anytime we apply partitioning or decomposition as part of a problem solving technique we are obligated to integrate and optimize to encourage that the whole comes together. The unfortunate thing here is that man must use the worst interface in the world through which the integration process must take place. It is called human communication. Note that the future will entail more thinner and deeper specialties requiring additional knowledge granularity. GENERALIST KNOWLEDGE BASE DOMAIN KNOWLEDGE BASE SPECIALIST KNOWLEDGE BASE c JOG System Engineering

Management Development In Reverse S = P:(A* x E* x I*) F P F E* I* I* A* c JOG System Engineering

Management We Seek To Forge Crowds Into Teams A POWERFUL UINIFYING FORCE COMMON VISION c JOG System Engineering

Management Organizational RAS ENTERPRISE PROCESS DEFINITION DEFINE PRODUCT DEFINE DESIGN VERIFY DESIGN F4231 F4232 F4333 ENTERPRISE FUNCTIONAL ORGANIZATIONAL STRUCTURE DEFINITION MODEL ENTITY MID F4231 F4232 F4233 NAME DEFINE PRODUCT DEFINE DESIGN VERIFY DESIGN TASK ENTITY DESCRIPTION ORGANIZATIONAL ENTITY DEPT 210 220 230 NAME SYSTEMS DESIGN VERIFICATION RAS DEFINE ALLOCATION OF FUNCTIONALITY D200 VERIFICATION SYSTEMS DESIGN D210 D220 D230 c JOG System Engineering

Organizing for Programs c JOG System Engineering Management Organizing for Programs ENTERPRISE FUNCTIONAL ORGANIZATION ENTERPRISE GENERAL MANAGER ENTERPRISE INTEGRATION TEAM (EIT) PROGRAM C PROGRAM B PROGRAM A PROGRAM A MANAGER PROGRAM INTEGRATION PRODUCT DEVELOPMENT PRODUCT PRODUCT PROGRAM DEVELOPMENT DEVELOPMENT BUSINESS TEAM TEAM 1 TEAM 2 TEAM 3 TEAM PRODUCTION PROGRAM A PROGRAM A PROGRAM A PROGRAM A DIRECTOR FUNCTION 1 FUNCTION 1 PIT PDT 1 FUNCTION 1 FUNCTION 1 PDT 2 PDT 3 PROGRAM A PROGRAM A PROGRAM A ENGINEERING DIRECTOR FUNCTION 2 FUNCTION 2 FUNCTION 2 PIT PDT 2 PDT 3 LOGISTICS PROGRAM A DIRECTOR FUNCTION 3 PDT 1 PROCUREMENT PROGRAM A PROGRAM A PROGRAM A DIRECTOR FUNCTION 4 FUNCTION 4 FUNCTION 4 PIT PDT 1 PDT 3 PROGRAM A PROGRAM A SCHEDULING FUNCTION 5 FUNCTION 5 DIRECTOR PIT PDT 1 LEGAL PROGRAM A PROGRAM A PROGRAM A PROGRAM A DIRECTOR FUNCTION 6 FUNCTION 6 FUNCTION 6 FUNCTION 6 PIT PDT 2 PDT 3 BUSINESS PROGRAM A PROGRAM A QUALITY FUNCTION 7 PROGRAM A FUNCTION 7 DIRECTOR FUNCTION 7 PIT PDT 1 PDT 3 CONTRACTS PROGRAM A PROGRAM A FUNCTION 8 FUNCTION 8 DIRECTOR PIT BUSINESS FINANCE PROGRAM A DIRECTOR FUNCTION 9 BUSINESS c JOG System Engineering

Hierarchical Integration Teaming c JOG System Engineering Management Hierarchical Integration Teaming CORPORATE Integration Paths SECTOR 1 Management Paths Integration Agent BUSINESS AREA 11 PROGRAM 113 SEIT PROJECT PROJECT PROJECT 1131 1132 1133 c JOG System Engineering

Management Typical Planning String GSD Approach IMP PLANNING STRING SOW ENTERPRISE F-STRINGS P05-S01 -E03 -A12-F122-D262 ENTERPRISE PROGRAM 05 PROGRAM PHASE 01 FUNCTIONAL DEPARTMENT SUPPLYING PERSONNEL DOING PROGRAM WORK (SEE EDD APPENDIX C) PRODUCT WBS/ARCHITECTURE ITEM A12 E00 E01 E02 E03 E04 E05 E06 CONTRACT AWARD SYSTEM REQUIREMENTS REVIEW SYSTEM DESIGN REVIEW PRELIMINARY DESIGN REVIEW CRITICAL DESIGN REVIEW FUNCTIONAL CONFIGURATION AUDIT PHYSICAL CONFIGURATION AUDIT PROCESS (SEE EDD APPENDIX A) c JOG System Engineering

Management Risk Index Values c JOG System Engineering

Management Aggregate Program Risk Index Over Time c JOG System Engineering

Management An Aggregate Assessment Metric 100 (100,100) (13,97) GOOD DOCUMENTATION WELL IMPLEMENTED I M AUDIT EVENT A P IDENTIFICATION Q S L POOR DOCUMENTATION S YEAR 2004 T E U WELL IMPLEMENTED E EVENT 001 A M A L S 50 TASK 121 S E S DEPT 877 K N I T M PROG 001 T E A Y N (38,29) T T I POOR O DOCUMENT- (98,15) N ATION GOOD DOCUMENTATION POORLY POORLY IMPLEMENTED IMPLEMENTED 50 100 PRACTICE DOCUMENTATION QUALITY ASSESSMENT c JOG System Engineering

c JOG System Engineering Requirements How Does the System Engineer Approach Unprecedented Problem Space? FUNCTIONAL FACET VISION OBJECT FACET PROBLEM SPACE The problems we must deal with become more complex over time. We use models to gain insight into these problem spaces. All of these models are implemented in simple charts using directed lines and simple geometric figures (blocks, bubbles) representing one or more perspectives of the problem space. The analyst while creating these diagrams applies hand-eye coordination and the most powerful channel for entering ideas into the human mind, vision. Over time each facet is represented by a set of simple diagrams. The unresolved problem space disappears and is replaced by a clear understanding of the space in terms of the simple diagrams and corresponding ideas in the minds of the team members. BEHAVIORAL FACET ANALYST c JOG System Engineering

Requirements Specification Generator TEMPLATE MAP METHODS AND DOMAINS TO TEMPLATE DOMAINS PUBLISH SPECIFI- CATIONS SPECIFI- CATIONS REQUIRE- MENTS ANALYSIS (RAS & DATABASE) METHODS We will look at the application of traditional structured analysis in order to develop the RAS-Complete ideas. But, the point is that any modeling approach can be used to feed the RAS-Complete. SYSTEM ARCHITECTURE REPORT PREPARE SAR SAR TEMPLATE c JOG System Engineering

Requirements RAS-Complete In Table Form c JOG System Engineering

Synthesis Where Do System Engineers Play? Knowledge Domains The Sand Box of the System Engineer Product Domains c JOG System Engineering

Synthesis Integration Skills ELEMENT Yi INTEGRATION ELEMENT Xi DOMAIN OF THE SYSTEM ENGINEER DOMAIN X DOMAIN Y c JOG System Engineering

Benefits of Product Team Organization c JOG System Engineering Synthesis Benefits of Product Team Organization WBS, SOW, IMP, IMS Budget and schedule Specifications ORGANIZATION N-SQUARE DIAGRAM IPT 1 IPT 2 Interface Control Working Teams Inter-team Communication Requirement IPT 3 IPT 4 SEGMENT 1 The DD(X) Program has organized in a fashion encouraging the most effective control of interface development and management. The program employs product oriented cross functional team which are physically collocated as much as possible considering the program brings together resources across the country. This method of organizing aligns the program organization with the product organization minimizing the management complexities and maximizing the accountability for cross organizational interfaces. The segment teams cooperate through the ICWG to ensure that all interfaces are identified and characterized within program interface documentation. Cross- Organizational Interface Requirement SEGMENT 2 Component Teams SEGMENT 3 SEGMENT 4 PRODUCT N-SQUARE DIAGRAM c JOG System Engineering

Synthesis The Fundamental Problems in Interface Work There is a one-to-one correspondence between teams and components. There is a one- to-two correspondence between teams and interfaces. COMPONENT X COMPONENT Y We assign teams as the responsible development agents for items in a system such as the segments, elements, and components of the DD(X) so there is a one-to-one relationship between architecture entities and responsible teams. Interfaces exist between pairs of system entities so there is a one-to-two relationship between the interfaces and responsible teams. c JOG System Engineering

Synthesis The Fundamental Problems in Interface Work We tend to focus inwardly COMPONENT X COMPONENT Y When we develop systems to satisfy very complex needs, it is necessary that we bring together many people because man’s knowledge base is tremendously large relative to the individual person’s knowledge capacity forcing us to specialize and on many teams because we must focus on the right level of granularity for ease of management. Unfortunately, people tend to look inwardly on these teams rather than leap across the line to see their interface from the other team’s perspective. c JOG System Engineering

Synthesis The Fundamental Problems in Interface Work We are dependent on the worst interface on planet Earth in the development of interfaces. COMPONENT X COMPONENT Y Since members of two different teams must develop an interface, the members of these teams must communicate across the team boundary. Human communications is not commonly a strong bond so we have to consciously strive for precision, understanding, and completeness in our interface communications. HUMAN COMMUNICATIONS!! c JOG System Engineering

V Model Encourages Good Requirements c JOG System Engineering Verification V Model Encourages Good Requirements DELIVERY NEED VERIFICATION PLANNING PLANE SYSTEM REQUIREMENTS SYSTEM TEST END ITEM REQUIREMENTS END ITEM TEST SUBSYSTEM REQUIREMENTS SUBSYSTEM TEST VERIFICATION REPORTING PLANE COMPONENT REQUIREMENTS COMPONENT TEST DEVELOPMENT DOWNSTROKE DEVELOPMENT UPSTROKE DESIGN & INTEGRATION c JOG System Engineering

Verification Verification Tracking Matrices SPECIFICATION VERIFICATION TRACEABILITY MATRICES UNION OF MATRICES VERIFICATION COMPLIANCE MATRIX TASK ONLY SCREEN INCLUDES EVERY VERIFICATION STRING VERIFICATION TASK TRACKING MATRIX VERIFICATION ITEM TRACKING MATRIX INCLUDES EVERY VERIFICATION TASK EACH OF WHICH IS COMPOSED OF MULTIPLE STRINGS ITEM ONLY SCREEN c JOG System Engineering

c JOG System Engineering Verification Documentation Stream 3.2.7 4.2.5.1 Table 4-1 Verification Traceability Matrix SPECIFICATION LIBRARY ITEM A1 ID A1 VTN 123 } Table C-1 Verification Compliance Matrix Table C-2 Verification Task Matrix Table C-3 Verification Item Matrix Table B-2 Verification Process Flow Diagram Table B-1 Verification Schedule INTEGRATED VERIFICATION MANAGEMENT REPORT INTEGRATED VERIFICATION PLAN (IVP) TASK REPORT (IVR) SAME PATTERN FOR QUALIFICATION USING ITEM PERFORMANCE SPECIFICATIONS SYSTEM USING SYSTEM SPECIFICATION ACCEPTANCE USING ITEM DETAIL SPECIFICAITONS IMPLEMENTATION ITEM A1 TASK 123 STATUS INFORMATION FCA PCA c JOG System Engineering